Hi, On Mon, Mar 5, 2012 at 1:36 PM, Marcel Reutegger <[email protected]> wrote: >> int getChildNodeCount(); > > this doesn't work well when you have concurrent child node > operations. e.g. one session adds a child node while another > session removes the child nodes.
We're talking about an immutable state here, so the child node count never changes for a given NodeState instance. > IMO it would be better if the number of child nodes is calculated > by the caller. why do we have the method anyway? ;) The caller may well want to adapt it's functionality depending on whether a node has 10 or 10M child nodes. >> Iterable<ChildNodeEntry> getChildNodeEntries(int offset, int length); > > doesn't this imply that the implementation will keep the child > nodes in a list? Any implementation that supports orderable child nodes is necessarily some form of a list. The only extra bit here is that I'm expecting the implementation to be able to use a numeric index instead of some other pointer to indicate the starting point. That should be easily doable with most models of persistence. Also, the current MicroKernel interface assumes that the underlying storage model is able to use numeric indices. BR, Jukka Zitting
