Ну я на такой задаче вообще не запариваюсь и использую AL. Получение всего дерева процесс безусловно рекурсивный, но в своей платформе просто сторю его полностью в сериализованном виде в кэше.
Нет, не выйдет. Конечно, время на сервере на момент запуска должно быть выставлено корректно. Учитывая зачастую поднятый по дефолту NTP это именно так и есть. Поэтому unix time в них корректный выставлен. А вот данные полученные в других форматах через tzdata могут оказаться некорректными при неактуальности последней. Если писать в базу что-то отличное от unix timestamp, то в базу пойдут некорректные записи которые исправить получиться только зная величину этой ошибки на момент записи. Если же писать в unix timestamp, то после того как будет поправлена tzdata, выдача даты из базы станет корректной, ведь в базе дата записана была корректно.
Если же на сервере время выставлено изначально криво, то уже не важно, в каком формате писать дату и кривая или нет tzdata. Запись в базу уйдет кривой в любом случае. Поэтому запись в формате unix timestamp это не панацея, но этот метод более устойчив к возможным ошибкам. К примеру, берем переход на летнее/зимнее время и админа, который забыл обновить tzdata. При unix timestamp данные в базу кривыми не уйдут.
Не говоря уже про в базе обычно этот тип требует под себя меньше объема.
Насчет опасности при доступе снаружи не согласен. Имхо, она возникает если нет уверенности в архитектуре проекта («ой, а вдруг, что-то где-то не экранируется...»).
Плюсы и минусы есть и там и там и они в принципе равноценные, но лично я схему работы с правами не сосредотачиваю ни в модуле, ни в роутере. Кстати, я различаю понятие доступа к модулю и права доступа. Доступ к модулю это возможность вызвать методы модуля в принципе. Этим занимается роутер. Он может преобразовать входящий URI в метод нужного модуля и обеспечивает передачу параметров в него. Модуль роутера абсолютно ни чего не знает про права, текущий модуль ни чего не знает про роутер. В итоге и модуль роутера и текущий модуль имееют очень низкую степень связанности. Как результат — переход, к примеру, от RPC к REST требует лишь смены роутера. Правами же доступа рулит третий модуль обеспечивающий ACL. Вот инстанс его объекта находится в свойстве текущего модуля и реализует метод isAllow(). Связанность и тут получается низкой с хорошей инкапсуляцией. Смена ACL модуля ни как не затрагивает связанный код, источник данных для ACL модуля так же личное дело самого ACL модуля и смена хранения инфы в файле может быть просто сменена на схему хранения в БД или вообще в AD, затрагивает это только код самого модуля.
В общем получается, что ограничение доступа реализуется ни в самом модуле, ни даже в роутере. Имхо, это упрощает код приложения в целом. Каждый модуль решает свою одну задача, pure unix way.
Кстати. Внесу наверное последних пять копеек в вопрос доступности модуля извне. Он должен быть доступен снаружи приложения, но не напрямую, а через модуль-роутер. А мотивация к этому не столько желания ограничения, сколько масштабируемость у целом. Потому как роутер знает входящий URI и знает в какой метод какого модуля ему соответствует, он может проводить нормализацию URI (к примеру, приводя ЧПУ к единому внутреннему формату), проводить проверку прав. Это позволяет не меняя кода самого модуля повесить его вызов на какой угодно адрес (если правила роутинга хранятся, к примеру, в базе, то и код роутера не меняется). Что не исключает варианта прямого вызова. В общем тут достаточно вариантов для маневра исходя из конкретное задачи.
1. Любой вариант жизнеспособен, даже Joomla живет и процветает. Но опять же, каждый исходит из своей практики. Мой опыт показывает, что необходимость в дефолтный видах очччень быстро вырождается. И получается, что поиск «в папке модуля» это лишняя дисковая операция. А самое узкое место в приложениях у нас по прежнему I/O на диске. Оно конечно решаемое, к примеру, держать в той же shared memory результат поисков (как кэш файлов nginx-а), но усложняет код пусть не модуля, но приложения в целом. А в итоге нафига, если клиентам нашего модуля все равно нужна своя разметка.
Поэтому у меня модули генерят данные и только данные. Они делают одну простую задача, каждый из них решает свою задачу, но делают это хорошо. Как результат при одном же серверном коде у каждого юзера в браузере может быть свой скин абсолютно не похожий на другие. А на сервере в кэше компактно лежат данные и только данные.
3. Вот видишь, а тут у тебя выходит «уже без видов». Выкидываем вид вообще, делаем модули доступными по REST и у нас из модуля или приложения в целом (ибо если даже код не в модуле, он все равно есть в приложении) выносится нафиг целая прослойка.
Просто наблюдая разные системы могу заметить, что народ наворачивает разные уровни абстракций, сдабривает разными паттернами, наворачивает разные ООП примочки, но мало кто думает, ну нафига все это. В результате такой код потом дороже в саппорте. Лично я агитирую за максимальную простату и специализированность кода. Модуль должен решать одну задачу и только её, код метода не должен быть больше 3-4 экранов, все связи модуля с другими модулями должны быть очевидны и понятны без сокрытия их в недрах приложения, т.е. минимизация использования разных «магических» методов. Все это справедливо в бОльшей степени для проектов ориентированных на группу разработчиков, но и для варианта когда с фрейворком работаешь только ты сам так же имеет вес. Потому как даже сам создатель и архитектор проекта по мере развития начинает забывать о конкретных деталях реализации того или иного участка системы. Цена кода, с точки зрения бизнеса, определяется вложениями не на первичную архитектуру, а на цену саппорта этого кода в дальнейшем.
1.
а) размер данных, меньше размер данных — больше можно положить в кэш;
б) у модуля может быть множество клиентов с множеством вариантов представления данных, но его это не заботит, конечный вид данных не его забота и значит код модуля проще и кода становится меньше, он более понятен, его проще поддерживать; в дефолтном представлении данных не вижу смысла, все равно коду-клиенту модуля понадобится какая-то другая структура (другая логика разметки, дополнительные классы, прочее), а если вид на столько прост что подошел бы и дефолтный, вот так пусть в коде-клиенте он и будет.
Веб проекты в свое развитии как правило эволюционные и «необходимость перекрытия» возникает очень быстро. Поэтому лично в моей практике дополнительная сущность «дефолтный вид» очень быстро становиться атавизмом мещающим поддержке кода модуля.
2. У класса модуля можно определить свойство в котором хранить объект (инстанс другого модуля по сути) определяющий правила доступа и для значимых действий (добавить/удалить/изменить) обращаться, допустим, к методу isAllow() этого объекта. При этом модулю совершенно не важно на основании чего принимается решение, он лишь получает булево значение можно/нельзя. А это объект может данные уже брать из файла конфига, из базы, принимать решение на основании IP клиента или еще исходя из других соображений, все это не важно в рамках текущего модуля. Такая архитектура приложения позволяет упростить код самого модуля, его проще отлаживать и поддерживать.
В любом случае модуль не может быть абсолютно независим (т.е. невозможно вытащить его из системы А и запихать в систему Б и при этом не потянуть за собой необходимость зависимостей), но его можно сделать слабо связанным и приведенный мою пример это один из вариантов этого.
3. Просто methodname уже говорит, что это не REST, а RPC. При REST у нас значимые действия задаются в виде HTTP методов.
Ну, возьмем модуль User. При твоем подходе, чисто гипотетически исходя из твоей схемы, для задач:
— получить список пользователей вызываем User/getList/viewGrid?filter[name]=Joe
— получить конкретного пользователя вызываем User/getProfile/viewList?user_id=20
— удалить конкретного пользователя вызываем User/delete/?user_id=20
А это RPC-style. Заметь, при такой схеме мне пришлось user_id вынести в параметры запроса. А теперь как теже задачи реализуются у меня:
— получить список пользователей шлем запрос GET методом на User/?filter[name]=Joe
— получить конкретного пользователя шлем запрос GET методом на User/20
— удалить конкретного пользователя шлем запрос DELETE методом на User/20
И ни каких видов внутри самого модуля. Данные генерированные модулем могут уйти в шаблонный движок, или на клиент или еще куда, не важно, в самом модуле у нас нет бизнес логики работы с видом. Опять же повторюсь, код модуля становиться проще, он более понятен, его проще отлаживать и поддерживать.
Удачность того или иного архитектурного решения проявляется как раз на уровне поддержки кода (на сколько сложно его модифицировать под новые условия, как сложно дебажить) и в меньшей степени его «переносимостью» потому как в вебе, особо в случае PHP код твоих модулей все равно будет работать в рамках какой либо системы/фреймворка/etc и его без напильника перенести на другую систему не получится.
Как я понимаю автор это не та личность о которой гипотетически говориться в топике. Имхо, даже наоборот, автор решает, лишить некую уходящую личность процента или нет.
2. Модуль приложения вообще не должен заботиться вопросами доступа. Он получил запрос, он обязан на него ответить. Если запрос требует аутентификации, то модуль так и должен отвечать. А ограничением доступа должен заниматься веб сервер или фаервол. Просто исходя из соображения, что у них это потребует меньше ресурсов, чем у приложения.
Это отдача чанками. Угробите сервер нафиг. Оно реального того не стоит. Не палки в колеса нужно ставить, а предоставлять такой уровень сервиса, что бы можно было удобно платить и по возможности недорого.
Оверхед конечно есть, но при современной железе мы чаще упираем в I/O на диске, чем в процессоры. Опять же на скидку более длинный ключ должен давать бОльший оверхед, чем более короткий и тут есть смысл разделять сертификаты, но учитывая важность алгоритмов криптографии и их массовость, то алгоритм уже на сколько обкатан в том числе и под железо, что все эти оверхеды лежат на уровне статистической погрешности.
Кто занимается грабингами сайтов те давно уже имеют на каждую возможную палку контрпалку. Так что все эти защиты от грабинга не защищают, ведь конкуренты не сами грабят, а наверняка нанимают людей занимающихся этим профессионально (на фрилансру таких заказов много, как и желающих их выполнить). Поэтому все палки отразятся не на них, а на посетителях сайта.
Аккредитованный регистратор говорит о том, что ему менее с руки разводить своих клиентов, чем тем же ресселерам. Но полностью развод не исключается. К примеру, регтайм продает домены в зоне.ру и не каждый купивший там домен понимает, что работает это только с iClient плагином для браузера, т.е. по сути не работает вовсе.
На сервере мало ОЗУ? Значит указанный движок не для вас. Тем более если не нужны транзакции и внешние ключи.
P.S. Взамен top рекомендую установить htop, там даже strace можно по быстро вызвать.