On Mon, Mar 5, 2012 at 2:10 PM, Jukka Zitting <[email protected]> wrote: > 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.
correct > >> 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. agreed cheers stefan > >>> 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
