You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by David Nuescheler <da...@gmail.com> on 2004/12/08 15:59:36 UTC
Re: Enhancement/Extension of JCR API
hi michi,
> 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?
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?
> 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. it largely depends on what you want to
achieve....
regards,
david
----------------------------------------------------------------------
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.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
Re: Enhancement/Extension of JCR API
Posted by Michael Wechner <mi...@wyona.com>.
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.
>
>
agreed
>>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.
>>>
>>>
>>ok.
>>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
>>>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.
>
>
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
Thanks
Michi
>regards,
>david
>----------------------------------------------------------------------
>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.
>
>
>mailto:david.nuescheler@day.com
>http://www.day.com
>
>David Nuescheler
>Chief Technology Officer
>Day Software AG
>Barfuesserplatz 6 / Postfach
>4001 Basel
>Switzerland
>
>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
Re: Enhancement/Extension of JCR API
Posted by David Nuescheler <da...@gmail.com>.
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.
regards,
david
----------------------------------------------------------------------
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.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
Re: Enhancement/Extension of JCR API
Posted by Michael Wechner <mi...@wyona.com>.
David Nuescheler wrote:
>hi michi,
>
>
>
>>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?
>
>
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
>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).
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.
>
>
>>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.
> it largely depends on what you want to
>achieve....
>
>
right, I often give the same answer, but now I am on the other side ;-)
Thanks
Michi
>regards,
>david
>----------------------------------------------------------------------
>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.
>
>
>mailto:david.nuescheler@day.com
>http://www.day.com
>
>David Nuescheler
>Chief Technology Officer
>Day Software AG
>Barfuesserplatz 6 / Postfach
>4001 Basel
>Switzerland
>
>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