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: Enhancement/Extension of JCR API
Date Wed, 08 Dec 2004 16:29:25 GMT
hi michi,

thanks for your response.

> >>I am currently facing the problem of a repository with certain features,
> >>which would be necessary but not covered by the JCR API.
> >when you say "would be necessary" do you mean for "general purpose"
> >or just for a very specific usecase?
well... that's generally right. however, it depends which one you are 
talking about: if it is something that we (the industry or the eg) would 
all agree that it is something that a repository is supposed to do
then it belongs into a later version of the spec (v1.1). if everybody
agrees that it should be in the application layer we should not add
it to the api, but should provide mechanisms that allow to extend
a repository elegantly to achieve this functionality.

> I guess what I am refering to could be both (please see below), but
> actually I became interested in general, I mean without refering to a
> specific usecase
i fear that there is not one generic way to extend "the api". what would
be the generic way to extend "the servlet api"? independant of what 
you want to do...

> >or let me ask differently, are you sure that this functionality would be
> >considered "generic repository functionality" and not application
> >functionality? what are you thinking of specifically?
> it's versioning and tagging of a set of nodes (e.g. like bitkeeper is
> able to do). Or does JSR-170 consider this? (sorry if I might have
> overlooked something).
when you say tagging a set of nodes this probably translates into 
jsr-170 lingo: "label a set of versions" ? you might want 
to look for jcr:versionLabels in the spec.

> But as I said above I guess there will always be specific use cases
> which aren't covered by the API, so it would be nice to know what the
> approaches are.
i would argue that most extensions should whenever possible be done 
on an application level (using the regular api) maybe adding new mixins, 
observation listeners, query syntaxes, etc.., etc...

> >>Is there a standard way of "enhancing the API"? Or any other approach?
> >there are different ways to extend jackrabbit functionality either jcr
> >based or jackrabbit specific.
> ok.
> I guess one way would be to do an explicit cast, but it doesn't seem so
> nice to do that.
cast what?

> > it largely depends on what you want to
> >achieve....
> right, I often give the same answer, but now I am on the other side ;-)
the reason why i am insterested to hear the specific reasons
for extesnions are two fold:

(a) not everyone has taken the time or has had the chance
to read the (latest) spec carefully, due to a variety of restrictions.
and it would be a shame if some early applications of jcr would
for example re-implement portions of let's say versioning just 
because certain features are not known to the repository 
application developer.

(b) because i would still like to find out if we missed some functionality
in jsr-170 that we need to consider extending either for v1.1 or earlier.

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