jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: contrib/jcr-ext proposal
Date Fri, 04 Feb 2005 17:12:57 GMT
hi jukka,

> After a busy week marketing the JCR idea here in Finland, it seems that
> I will be working on JCR related projects quite actively during the
> spring, especially after the final release of the API is available.
sounds fantastic.

> As a part of these projects I will end up creating a set of general
> purpose JCR components that I'd like to release as open source and
> contribute to the Jackrabbit project as a contrib package like the
> JCR-RMI layer I implemented earlier.

> This message is my concrete proposal for a contrib/jcr-ext (as in JCR
> extras/extensions) package. I'd also like to reserve the
> org.apache.jackrabbit.ext name for this package. If you think a contrib
> package like this would fit with Jackrabbit, then I will continue my
> work on it and provide periodic snapshots for inclusion with Jacrabbit.
> Below is a listing of the various components I plan to implement. I
> already have some code for the .xml, .decorator and .cache components,
> but mostly this is just vaporware for now. However, with my current
> funding, I expect to be able to deliver at least a part of these tools
> during the next month or two.
>   o.a.j.ext.xml - XML import/export support
>     Utility classes that implement the XML import/export functionality
>     of JCR using the standard JCR Node API. (Jackrabbit implements
>     similar support classes, but they operate below the JCR API.)
>     Makes it easy for JCR implementations to support the XML operations
>     once the basic Node read/write functionality exists.
hmmm... ok, i see. which would mean that jackrabbit becomes a bit of
a repository-sdk.. fine with me. personally, i believe that import
specifically with respect to uuid and operations on protected 
properties has to be under the hood, which is the reason
why jackrabbit uses internal calls.

>   o.a.j.ext.inmemory - Simple in-memory JCR repository implementation
>     A trivial in-memory implementation of the most basic JCR repository
>     functionality. Designed for simple demo and testing purposes.
sounds interesting ;)

>   o.a.j.ext.typenode - Generic /jcr:system/jcr:nodetypes implementation
>     A node tree implementation that is backed by the NodeTypeManager
>     API. Makes it easy for JCR implementations to make the
>     /jcr:system/jcr:nodetypes subtree available once the NodeTypeManager
>     implementation exists.
hehe ;)

>   o.a.j.ext.decorator - Generic JCR decorator layer
>     Decorator layer for the entire JCR API. Makes it easy to decorate
>     JCR implementations with extra functionality.
>   o.a.j.ext.cache - JCR caching layer
>     A decorator layer that provides caching of repository data and the
>     transient state of the client.
this is something that we are looking into aswell for the complete
mapping of jcr over webdav(+friends). maybe we can help each 
other, we can probably soon share with you what we already have.
>   o.a.j.ext.trace - JCR call trace layer
>     A decorator layer that writes a log of all JCR API calls.
cool. sounds like "jcr-truss" or "jcr-strace" to me ;)
and if we consolidate the calls then we would get something
that i sometimes called the "jcr-fingerprint" of an application.
which helps people to see what type of repository functionality
(or jcr calls) their application requires.

>   o.a.j.ext.audit - JCR audit trail layer
>     A decorator layer that writes an audit trail of all users accessing
>     a content repository.
well, let's see how that works with the transactions, but i think it is
a good idea.

>   o.a.j.ext.security - Security and access control layer for JCR
>     A decorator layer that guards access to a content repository using
>     JAAS access control and the Java permission architecture.
we are also working on that right now... maybe we can team up.

great ideas.


standardize your content-repository !
---------------------------------------< david.nuescheler@day.com >---

This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.

The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.


David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel

T  41 61 226 98 98
F  41 61 226 98 97

View raw message