jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Implementing virtual, per session subtree
Date Fri, 09 Nov 2007 10:40:21 GMT
hi berry,

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.


(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.

View raw message