Hi David, Personally, I think that there are going to be more volatile and less volatile paths in a content repository based on many different characteristics of the application(s) running on the repository. Generally SNS paths are less stable because they are not only impacted by "moves" of the node or an ancestor node but also by removals or additional of sibling nodes.
I agree with you that, if one requires a stable identification of a node a path to an SNS node is a poor nodetype design that I would certainly not recommend. Alternatively I would recommend to use a referencable node or stay away from SNS. Personally, I would even go further and state that SNS should be used in exceptional cases only and with great caution, in general. I will gladly forward this post to [EMAIL PROTECTED] for discussion in the Expert Group, and would encourage anyone to post specification enhancement to the above address. regards, david On 9/26/06, David Kennedy <[EMAIL PROTECTED]> wrote:
I'd like to bring up the issue of compaction of indices with regard to same-name-siblings again. Compaction pretty much renders same-name-siblings useless if you refer to nodes via path. In a muti-user environment, and any point one user can move a node, thus changing the path of any following sibling referenced by other sessions. If an application maintains proxy data by path reference, the node may exist, however with a completely different path. Either applications need to make all nodes referencable and manage via UUID or avoid SNS. Has the EG's direction with regard to SNS compaction changed in JSR-283? David
