это становится совсем интересно... :)

Misha v.3 28.10.2003 12:30

начну с конца:

Мне очень понравилась идея провести аналогию с NDS.
Бросаются в глаза отличие.
В NDS пользователи и группы тоже являются объектами.
И на них можно давать права!

да, несомненно, однако и сама NDS обслуживается поднятым и постоянно работающим сервером, мне-же приходится заниматься подобными вычислениями в каждом CGI процессе. это несколько разные вещи, и мне приходится чем-то жертвовать. я пожертвовал размещением пользователей/групп (они вне дерева), т.к. далеко не всегда мне они вообще требуются :)
но я сначала пытался хранить их в дереве. вычисления получились очень громоздкими...

Тогда, для определения доступов к объекту child2 мы вытаскиваем доступы к объекту child1 (и всем его потомкам, не так ли), что нам совершенно не нужно.

в принципе у меня есть такое понятие у объекта как nesting, т.е. я могу достать не весь тред, а ограничить его снизу/сверху. но я все равно не делаю этого. почему?
очень просто: я посмотрел статистику (MAIN:pSQL с его статистикой рулит) и увидел, что достато одним запросов тред (даже довольно большой) значительно экономичнее чем делать N запросов и доставать N объектов (при этом естественно единожды запрошеный из БД объект я кеширую).
ситуация была-бы иной если бы у меня был daemon...

Получается, что нужно писать весьма сложный код для создания параметра thread перед вызовом метода @getRightsToObject[object;thread;acl;is_owner].

нет, не получается. код почти всегда одинаков. примерно такой как я привел. в моем случае он еще упрощается, т.к. в engine я все равно достаю текущий тред.

к тому-же не забывайте, что может требоваться решение разных задач, например для доступа к сайту решается задача "какие пользователь имеет права на данный объект", а например в административном интерфейсе возникает и такая задача: "нужно получить все объекты на которые пользователь имеет права видеть их"

Мне представляется, что проще в классе auth определить виртуальный метод getObject[object_id]...

если делать совсем красиво, то надо скармливать этому методу объект другого класса (например object) у которого есть все эти методы.
тут мне просто не хватает реальных задач, на которых я смог-бы понять что нужно решать чаще всего и как это делать лучше. для моих немногочисленых применений текущей реализации хватает.

Поле acl тоже не нужно, его можно получить по объекту.

тут опять не согласен (нету демона у нас), поэтому я достаю для заданного пользователя его полный ACL на все объекты, и больше не возвращаюсь к SQL запросам. именно поэтому тут приносится в жертву атомарность операций.

---