Pierangelo Masarati wrote:
Probably a simpler approach would be to have a different type of dynamic group that's rather a "cachedGroup"; a background thread could take care of keeping it updated by expanding dynamic members into static (and indexed), while direct modifications could be trapped and handled explicitly (e.g. if a memberURL is added/removed). The drawback would be that other updates to the database (like another user entering the scope of a memberURL search) are not immediately reflected in group membership. Static members should also be treated specially; this could be perhaps be done by subtyping the dynamically cached members from the static ones, so that regular searches for the static member attribute find both, but caching operations only deal with the dynamically generated ones.
This approach would definitely be simpler, but I see 2 deficiencies:
1. For large directories, the background thread scanning the whole database over and over could become a serious performance parasite 2. The thread could do the task very slowly and dynamic group data would be often stale, causing all sorts of problems, especially with objects which have their DNs changed.
Ad 2. - I can imagine lots of problems spanning from this - e.g. when a user is moved to a different subtree (e.g. the directory structure is based on localities, and a user moves to a different city), until the background thread updates the static member list, he loses any rights stemming from his dynamic group memberships, because he works with a new DN, while the static member lists are still using the old one. That's also a problem with ordinary static groups, but in their case the directory management tools usually take care of maintaining referential integrity, while there will be no way to order the background thread to refresh the groups immediately (or do it faster than currently if it runs continuously).
The approach I've suggested is definitely quite hard, and I can see that even commercial directory servers usually hava an Achilles feet WRT dynamic groups here, but it would provide the exact functionality that the user expects, without any gotchas. Maybe I won't succeed in implementing it, but it's worth trying (or considering at least).
-- Aleksander Adamowski Administrator systemów korporacyjnych; Instruktor Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Chłodna 51
kom. 0-601-318-080
Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione. Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message.