Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of jukka.zitting@gmail.com
 designates 66.249.82.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=Tm+rxzfFLqzyZSOJ2hBLnxF6vvBweerqvNQPE//Gp0+MS/OvEZwtu0S9LO7MBLZzbmJgO1BIyCHamYOJ/W/aOYQ3N7SI5InSpLd4b/byPYi80M8/C14nwmqpy3xc99VqnUETkTVG1cdT8N9Dp7iuhLKXNw8Dsus53/9QLaSf61s=
Message-ID: <510143ac0611210038h17876114t6849d1e82fda0d5e@mail.gmail.com>
Date: Tue, 21 Nov 2006 10:38:48 +0200
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Flat content hierarchies
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

I just opened a major improvement request, JCR-642 "Support flat
content hierarchies". I'd like to use the issue as the focus point for
building a roadmap for and eventually implementing the changes
necessary to get rid of the current limitations against flat content
structures.

There is no reason why a JCR content repository should not be able to
store flat content, and there are a number of applications where the
inherent content structure is indeed flat. Thus I think this is an
important issue to discuss and resolve.

The main problem with resolving the issue is the current design and
assumptions around the NodeState class. Much of the Jackrabbit core
implicitly assumes that the list of child nodes is always readily
available as a part of the NodeState instance. I don't think that
there's an easy or fast solution to this issue, so for now I think
it's enough to just start paying attention to this issue and perhaps
record potential concerns in JCR-642 whenever you come across them in
the core codebase.

BR,

Jukka Zitting