jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wechner <michael.wech...@wyona.com>
Subject Re: Enhancement/Extension of JCR API
Date Wed, 08 Dec 2004 22:02:55 GMT
David Nuescheler wrote:

>hi michi,
>thanks for your response.

thank you :-)

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


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

ok, I will check that out

>>>there are different ways to extend jackrabbit functionality either jcr
>>>based or jackrabbit specific.
>>I guess one way would be to do an explicit cast, but it doesn't seem so
>>nice to do that.
>cast what?

cast to the specific implementation of a specific repository.

>>>it largely depends on what you want to
>>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.

well, I need to read the spec as you pointed out re tagging a node set 
if this is what I am looking for. Will send a note when I will find out.

Generally speaking I would say it's what you state above:

1) generic stuff which most repositories share or at least to a certain 
level (whereas I assume there is still room for a compliance level 3) 
and should belong to JCR

2) repository specific stuff, which might be implemented only by one out 
of 10 repositories, but nevertheless can be useful for certain applications
and I guess such cases will always occur. Well, maybe it's indeed the 
job of the guy who is developing the application to take care of this 
such that somehwere in the future it might be part of the JCR and the 
repository could be switched again without too much refactoring



>standardize your content-repository !
>                               http://www.jcp.org/en/jsr/detail?id=170
>---------------------------------------< 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

Michael Wechner
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner@wyona.com                        michi@apache.org

View raw message