Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 14 Nov 2007 09:24:01 +0100
From: "(Berry) A.W. van Halderen" <b.vanhalderen@hippo.nl>
To: dev@jackrabbit.apache.org
Subject: Re: Implementing virtual, per session subtree
Message-ID: <20071114082401.GA16268@had13.hippointern.lan>
References: <20071107100932.GA5270@had13.hippointern.lan>
 <47343915.2030703@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47343915.2030703@gmx.net>
User-Agent: Mutt/1.4.2.2i

On Fri, Nov 09, 2007 at 11:40:21AM +0100, Marcel Reutegger wrote:
> that's quite a unusual functionality you propose. why do you want to expose 
> this additional data as item? I would rather implement an event listener 
> and simply keep the volatile information in a data structure of my 
> application.

Yes, we definitely want to expose this additional data as items.  The whole
point is that it allows the repository to expose information about itself
in the JCR tree.  Much like the jcr:system tree in one way, but now session
dependend.  We can build faceted navigation and views this way.

You don't actually want this at the application side.  The whole point
of a (JCR) repository is that you put core functionality in one place,
instead of having to duplicate this functionality.

Instead of using a proprietary repository or proprietary extensions for JCR,
which would still imply you have to adapt your application to use the
additional functionality, it is better to just expose additional functionality
in JCR itself.  Any JCR application can in principle use it, as it is still
JCR compliant.

> regards
>  marcel

Regards back,
\Berry

> (Berry) A.W. van Halderen wrote:
> >Dear list,
> >
> >I'm not hitting any direct problem at this time, but want to vent some of 
> >my
> >ideas on how to implement a certain extension on this list.  Such that you 
> >can
> >shoot at me if I'm doing something totally evil ;-)
> >
> >The final functionality I'm building goes a bit far, but for the sake of
> >discussion I can summarize by mentioning the two main ingredients needed.
> >
> >One functionality needed is that in certain cases, typically marked by a
> >save() or refresh() (tbd), child nodes and properties are automatically
> >re-created using some algorithm.  The values of the properties and which
> >children to generate might be dependent on the state of whole different 
> >parts
> >of the JCR tree.
> >
> >The other base functionality that these generated item states are actually
> >never persisted.  Their information is volatile because it can be 
> >re-created.
> >
> >For example and the sake of argument, one property might get an integer 
> >value
> >with the count of all nodes in the repository at the moment of save() or
> >refresh().
> >
> >This state differs per session, and should therefor (and for other reasons)
> >not be persisted.  Basically we have a virtual layer, not suppost to be
> >edited, but which is different from VirtualItemStateManagers because they 
> >are
> >distinct per session.
> >
> >Okay, that is the base I'm trying to achieve.  Now this functionality I've
> >already implemented as a prototype using decorating the entire JCR layer.
> >However this pattern has too many problems.  One is that it is too much 
> >work
> >to support all JCR calls and the other is that this does not integrate well
> >with caching and a session would over time accumulate to much memory.
> >Basically it is implemented in the wrong layer.
> >
> >I dove right down into JackRabbit, and came to the preliminary conclusion 
> >that
> >the way in this could fairly neatly (we're not going beauty contest) be
> >handled is largely in the ChangeLog kept by the LocalItemStateManager.  
> >This
> >would mean subclassing the LocalItemStateManager, but most code is 
> >actually in
> >a extended ChangeLog.  The proper handles are available and I was able to
> >prototype the functions needed.  So I'm not really asking how I should 
> >start
> >implementing this.
> >
> >However I do want to throw this into the JR community to see the reactions
> >and whether I'm not overlooking things, or whether I'm going 666 on the
> >design of JR...
> >
> >Regards,
> >\Berry
> >
> >PS, references from real nodes to virtual nodes are not supported, by 
> >design,
> >so I did take that into account.
> >

-- 
Berry A.W. van Halderen           b.vanhalderen@hippo.nl / berry@halderen.net
Disclaimer: the above is the author's personal opinion and is not the opinion
or policy of his employer or of the little green men that have been following
him all day.