jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "(Berry) A.W. van Halderen" <b.vanhalde...@hippo.nl>
Subject Implementing virtual, per session subtree
Date Wed, 07 Nov 2007 10:09:32 GMT
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.

Mime
View raw message