> I'm OK with that tradeoff. Basically we're saying that child nodes are > both ordered (in some stable order) *and* orderable (in that they can > be explicitly ordered). This means that the MK implementation must > store explicit ordering information for nodes, which can be a bit > costly for large nodes, as you mention below.
I'm not sure this is really about the cost. I rather have concerns about contention and conflicts in the distributed case. in a distributed environment you can scale concurrent child node adds more easily when they are unordered. in the ordered case you will likely have clients that simply add nodes without explicit order information, which means they are all added to the end of the list, causing contention in this area. Regards Marcel
