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