Hi,

On 11/14/06, Angela Schreiber <[EMAIL PROTECTED]> wrote:
and maybe the following issue is related to yours:
yukka and marcel recently discussed the the design
of the NodeState within jackrabbit and the jcr2spi.
based on this discussion we are going to redefine
the childNodeEntries concept. either of them may
shed some more light on this...

Quick notes on that, I'll follow up with a more detailed analysis of
the whole problem space later on.

The main issue we identified was that currently the SPI layer expects
to be able to read all the information exposed by NodeInfo when that
node is first seen. This creates extra burden on backend
implementations that can efficiently retrieve just a part of the
information.

A good illustration of this problem is a repository where the list of
children of a node is not returned when you request the details of a
node. The current SPI however expects the list of child identifiers to
be available when the NodeInfo instance is returned, so the
implementation would need to fire an extra call to retrieve the list
of child nodes. If I have a content tree with a 100 top level nodes
each containing 100 child nodes, then listing the names of the 100 top
level nodes would force the retrieveal of (at least the identifiers
of) all the 10k child nodes.

The initial idea on solving this is to move the call for getting the
list of child identifiers away from the NodeInfo interface.

BR,

Jukka Zitting

Reply via email to