Thanks, again. --noriko Andrey Ivanov wrote:
I've seen some changes in the USN design document, so i'll add my two cents. Overall it's well written, the architecture seems to be rather robust. There are some scenarious that are interesting for us as for the behaviour of the usn plugin and some questions/reflections : * The USNs seem to be unique within a suffix/backend. Should we enable the uniqueness plug-in for them? If not can we be sure that a manual change of entryUSN will not interfere with the correct functioning of the plug-in? * When the plug-in is activated no entry has entryUSN or maybe some entries do already have it in some desorder. Maybe we should initialise (while plug-in in started for the VERY first time) all the entries without entryUSN with entryUSN=-1 or smth like that? * Maybe it's a good idea to desactivate the replication of entryUSN attribute during the server installation by default? * When we do an export with a utility like db2ldif.pl - should the entryUSN attributes be exported or not? * What happens during the import of a whole ldif subtree by smth like "ldif2db -n userRoot -i /tmp/current_prod_database.ldif" if the entryUSNs are already present in the imported ldif? If they are not present? if they are present only in a part of the entries? * Should usn-tombstone-cleanup be integrated in the server core with the thread purging the tombstones ot not? Should it be configurable bo some attributes like nsds5ReplicaPurgeDelay and nsds5ReplicaTombstonePurgeInterval? And thank you for your work! -- 389-devel mailing list 389-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- 389-devel mailing list 389-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
