You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Angela Schreiber <an...@day.com> on 2005/12/08 12:27:14 UTC
Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
hi brian
please apologize, but i start feeling a little embarrassed.
one aim of the config was, to remove the hardcoded check
in the simple/DavResourceImpl, which repository nodes
should be treated as webdav collection resources and which
represent a normal resource.
the current configuration allows to define either the
collection nodetypes or the non-collection nodetypes...
thats what i considered to be the useful cases and which
of cause is just one way to look at it and i'm not saying
i found the only and not even the best way to deal with
this.
now to your change: you define that the root node
should always be a collection. of cause this is the
desired result, because otherwise you won't get huge
benefit out of your webdav.
but i don't agree that it's correct to hardcode it
into the ResourceConfig. if it turns out that the config
as is does provide enough flexibility and you run
into problems (thus your configuration resulted in a
non-collection root), i'd say that the way the config was
designed is wrong and should be reviewed.
maybe you can explain, what kind of troubles you had
with the configuration as is?
thanks for your comprehension
angela
bcm@apache.org wrote:
> Author: bcm
> Date: Wed Dec 7 09:48:29 2005
> New Revision: 354818
>
> URL: http://svn.apache.org/viewcvs?rev=354818&view=rev
> Log:
> always treat the root node as a collection resource.
> --- incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java (original)
> +++ incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java Wed Dec 7 09:48:29 2005
> @@ -200,6 +200,10 @@
> boolean isCollection = true;
> Node n = (Node)item;
> try {
> + if (n.getPath().equals("/")) {
> + // the root node always represents a collection
> + return true;
> + }
Re: webdav server(s)
Posted by Brian Moseley <bc...@osafoundation.org>.
Roy T. Fielding wrote:
> I think I understand now the disjoint thoughts on how the jcr-server
> should be designed. The existing jcr-server is a webdav view of a
> JCR repository, whereas it seems Brian is looking for a general
> webdav server that happens to use JCR as its storage interface.
> The reason for the confusion is because JCR and WebDAV do not share
> the same hierarchical models -- either one can emulate the other,
> but they are not the same.
yes. i apologize for failing to articulate this clearly over the
previous months.
> What I suggest is that we start a separate contrib project for a
> general webdav server implemented using JCR and see how much of
> the code can be shared between the two, gradually merging them
> together until we reach a point where the two are (hopefully)
> distinguishable only by configuration files. What do you think
> of that as a plan?
i like it. i can pretty easily extract the non-caldav stuff from cosmo
as a quick start. what do you suggest as a name for the project?
Re: webdav server(s)
Posted by Brian Moseley <bc...@osafoundation.org>.
Stéphane Croisier wrote:
> So the best solution would certainly be to open a new "dav.apache.org"
> top level project which would include a Slide 3.0 full refactoring based
> on Jackrabbit (or whatever would be the new name of such a project) and
> try to gather all the currently scarce DAV ressources and expertises
> into one single project.... Then CalDAV or other DAV extensions would
> then also easily fit in such a new TLP...
it would certainly be interesting to get all of the folks interested in
dav talking in one place.
AW: webdav server(s)
Posted by Daniel Florey <da...@web.de>.
> -----Ursprüngliche Nachricht-----
> Von: jackrabbit-dev-return-4917-daniel.florey=web.de@incubator.apache.org
> [mailto:jackrabbit-dev-return-4917-
> daniel.florey=web.de@incubator.apache.org] Im Auftrag von Stefan
> Guggisberg
> Gesendet: Donnerstag, 15. Dezember 2005 14:45
> An: jackrabbit-dev@incubator.apache.org
> Betreff: Re: webdav server(s)
>
> On 12/15/05, Daniel Florey <da...@web.de> wrote:
> > Hi folks,
> > this in an interesting thread.
> > It would be great to have a full featured WebDAV-stack implemented in
> Java
> > with a simple and consistent api.
> > When the Jackrabbit project started, I was little bit frustrated that
> people
> > started to reinvent the wheel instead of using simple
> > WebDAV-to-java-method-mapping as api. So I stuck with the Slide project
> even
> > though the codebase is really a mess and nobody really likes to work on
> it.
> > If there would be a combined effort to implement a robust WebDAV-stack,
> I'd
> > really appreciate this.
> > Let me summarize the goals of such a project from my point of view:
> > 1. The big advantage of WebDAV is that users can (in theory) use
> existing
> > clients to communicate with the server. There are many clients
> supporting
> > the very basic WebDAV set, but not many using any advanced WebDAV-
> features
> > (Delta-V, DASL, ACL).
> > The best WebDAV-clients supporting Versioning (and this seems to be the
> > hardest part to implement) are subclipse and TortoiseSVN.
> > So my primary goal of an apache WebDAV-project would be to be
> interoperable
> > with subversion. This could also include close communication with the
> > subversion team and perhaps changes to make subversion more WebDAV-
> compliant
> > and discussions on the DeltaV-mailing list to incorporate extensions
> that
> > subversion introduced into the spec if necessary.
> > It could be part of the WebDAV-project to provide new features for the
> > subclipse-Plugin to support ACL, DASL, Bindings and other WebDAV-
> features
> > right out of eclipse.
> > This could lead to a RCP-solution to provide a robust and mature
> > cross-platform WebDAF-client.
> > 2. Support of all important specs that you can find on Julian Reschke's
> > great webdav site:
> > http://www.greenbytes.com/tech/webdav
> > 3. The server implementation should be open to make it possible to add
> > support specs easily. This requires a good concept of virtual resources
> and
> > live/dead properties. But theses details can be discussed later on.
> > 4. Provide a single api for both local and remote repository
> communication.
> > In case of remote repository communication of course WebDAV should be
> used
> > as a protocol to enable communication with existing WebDAV-servers (Ms
> > Exchange, SAP Netweaver, Software AG's Tamino-Server etc).
> > 5. Support for feature examination. The api should reflect the different
> > levels of WebDAV support that the server provides. ACL's can be exposed
> in
> > different ways, some specs may not be supported by certain servers. This
> > should be reflected in the api.
> >
> > We are currently discussing to move Slide to TLP at the
>
> just wondering what the benefit would be of promoting a dead project to
> TLP...
>
> cheers
> stefan
If you are really interested in this, you can follow this thread:
http://mail-archives.apache.org/mod_mbox/jakarta-slide-dev/200512.mbox/%3c31
cc37360512121541v683b7b64q2675706b3f6f5bf@mail.gmail.com%3e
Peace brother,
Daniel
>
> > Slide-dev-Mailinglist. Personally I'd prefer to create a new
> > webdav.apache.org TLP and start something more elegant from scratch. If
> > there is a chance to combine the efforts taken in the Slide and in the
> > Jackrabbit project concerning the WebDAV support, I'd be glad to support
> > this effort.
> >
> > Cheers,
> > Daniel
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: jackrabbit-dev-return-4903-
> daniel.florey=web.de@incubator.apache.org
> > > [mailto:jackrabbit-dev-return-4903-
> > > daniel.florey=web.de@incubator.apache.org] Im Auftrag von Robert r.
> > > Sanders
> > > Gesendet: Mittwoch, 14. Dezember 2005 20:27
> > > An: jackrabbit-dev@incubator.apache.org
> > > Betreff: Re: webdav server(s)
> > >
> > > As someone who has been monitoring both Jackrabbit and Slide lists
> this
> > > idea struck me before. If the people still working on Slide could be
> > > brought over to work with some of the Jackrabbit people it seems to me
> > > that this would be in the best interests of both communities. I don't
> > > know how this would be done, or wether a TLP or a subproject would be
> a
> > > better alternative. While they aren't the same (and I am not an expert
> > > on either) it seems obvious that there are some gains to be made by
> > > having a full featured WebDAV server with a JCR backend.
> > >
> > > Stéphane Croisier wrote:
> > > >
> > > > There is a thread running on right now on the Slide Dev List about
> > > > moving Slide to a Top Level Apache Project (TLP). Currently we are
> > > > using Slide as a temporary solution to store some binary files for
> our
> > > > CMS and I agree quite a lot with the conclusions of Brian... The
> Slide
> > > > project is nearly dead and without nearly any activities from
> > > > beginning of this year.
> > > >
> > > > So the best solution would certainly be to open a new
> "dav.apache.org"
> > > > top level project which would include a Slide 3.0 full refactoring
> > > > based on Jackrabbit (or whatever would be the new name of such a
> > > > project) and try to gather all the currently scarce DAV ressources
> and
> > > > expertises into one single project.... Then CalDAV or other DAV
> > > > extensions would then also easily fit in such a new TLP...
> > > >
> > > > My 2 cts...
> > > > Stéphane
> > > >
> > > > At 17:31 14.12.2005, Brian Moseley wrote:
> > > >> Stefano Mazzocchi wrote:
> > > >>
> > > >>>> personally, i have no interest in working on such a thing. i
> > > >>>> wouldn't tell somebody not to do it, but i wouldn't help them
> either.
> > > >>> Can you tell us why?
> > > >>
> > > >> i found the slide codebase to be extremely confusing, verging on
> > > >> incomprehensible. i was unable to make heads or tails of the apis
> and
> > > >> had only the vaguest inkling of how i might extend it for caldav.
> > > >>
> > > >> by contrast, the jcr-server design is relatively simple and
elegant,
> > > >> and the extension points are natural and obvious.
> > > >>
> > > >> also the slide community didn't seem to have much momentum back in
> > > >> the spring of 2005. there was no defined release plan and extremely
> > > >> little support on the mailing list. the documentation that existed
> > > >> was sparse and often frustratingly unintelligible, so when you had
> > > >> questions, you were basically screwed.
> > > >>
> > > >> things might have changed for the better with slide, but i'm not
> > > >> optimistic. i vastly prefer the jackrabbit code and community.
> > > >
> > > > - -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- -
> > > > www.jahia.org : The Java Unified Web Platform
> > > >
> > >
> > > --
> > > Robert r. Sanders
> > > Chief Technologist
> > > iPOV
> > > (334) 821-5412
> > > www.ipov.net
> >
> >
> >
Re: webdav server(s)
Posted by Stefan Guggisberg <st...@gmail.com>.
On 12/15/05, Daniel Florey <da...@web.de> wrote:
> Hi folks,
> this in an interesting thread.
> It would be great to have a full featured WebDAV-stack implemented in Java
> with a simple and consistent api.
> When the Jackrabbit project started, I was little bit frustrated that people
> started to reinvent the wheel instead of using simple
> WebDAV-to-java-method-mapping as api. So I stuck with the Slide project even
> though the codebase is really a mess and nobody really likes to work on it.
> If there would be a combined effort to implement a robust WebDAV-stack, I'd
> really appreciate this.
> Let me summarize the goals of such a project from my point of view:
> 1. The big advantage of WebDAV is that users can (in theory) use existing
> clients to communicate with the server. There are many clients supporting
> the very basic WebDAV set, but not many using any advanced WebDAV-features
> (Delta-V, DASL, ACL).
> The best WebDAV-clients supporting Versioning (and this seems to be the
> hardest part to implement) are subclipse and TortoiseSVN.
> So my primary goal of an apache WebDAV-project would be to be interoperable
> with subversion. This could also include close communication with the
> subversion team and perhaps changes to make subversion more WebDAV-compliant
> and discussions on the DeltaV-mailing list to incorporate extensions that
> subversion introduced into the spec if necessary.
> It could be part of the WebDAV-project to provide new features for the
> subclipse-Plugin to support ACL, DASL, Bindings and other WebDAV-features
> right out of eclipse.
> This could lead to a RCP-solution to provide a robust and mature
> cross-platform WebDAF-client.
> 2. Support of all important specs that you can find on Julian Reschke's
> great webdav site:
> http://www.greenbytes.com/tech/webdav
> 3. The server implementation should be open to make it possible to add
> support specs easily. This requires a good concept of virtual resources and
> live/dead properties. But theses details can be discussed later on.
> 4. Provide a single api for both local and remote repository communication.
> In case of remote repository communication of course WebDAV should be used
> as a protocol to enable communication with existing WebDAV-servers (Ms
> Exchange, SAP Netweaver, Software AG's Tamino-Server etc).
> 5. Support for feature examination. The api should reflect the different
> levels of WebDAV support that the server provides. ACL's can be exposed in
> different ways, some specs may not be supported by certain servers. This
> should be reflected in the api.
>
> We are currently discussing to move Slide to TLP at the
just wondering what the benefit would be of promoting a dead project to TLP...
cheers
stefan
> Slide-dev-Mailinglist. Personally I'd prefer to create a new
> webdav.apache.org TLP and start something more elegant from scratch. If
> there is a chance to combine the efforts taken in the Slide and in the
> Jackrabbit project concerning the WebDAV support, I'd be glad to support
> this effort.
>
> Cheers,
> Daniel
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: jackrabbit-dev-return-4903-daniel.florey=web.de@incubator.apache.org
> > [mailto:jackrabbit-dev-return-4903-
> > daniel.florey=web.de@incubator.apache.org] Im Auftrag von Robert r.
> > Sanders
> > Gesendet: Mittwoch, 14. Dezember 2005 20:27
> > An: jackrabbit-dev@incubator.apache.org
> > Betreff: Re: webdav server(s)
> >
> > As someone who has been monitoring both Jackrabbit and Slide lists this
> > idea struck me before. If the people still working on Slide could be
> > brought over to work with some of the Jackrabbit people it seems to me
> > that this would be in the best interests of both communities. I don't
> > know how this would be done, or wether a TLP or a subproject would be a
> > better alternative. While they aren't the same (and I am not an expert
> > on either) it seems obvious that there are some gains to be made by
> > having a full featured WebDAV server with a JCR backend.
> >
> > Stéphane Croisier wrote:
> > >
> > > There is a thread running on right now on the Slide Dev List about
> > > moving Slide to a Top Level Apache Project (TLP). Currently we are
> > > using Slide as a temporary solution to store some binary files for our
> > > CMS and I agree quite a lot with the conclusions of Brian... The Slide
> > > project is nearly dead and without nearly any activities from
> > > beginning of this year.
> > >
> > > So the best solution would certainly be to open a new "dav.apache.org"
> > > top level project which would include a Slide 3.0 full refactoring
> > > based on Jackrabbit (or whatever would be the new name of such a
> > > project) and try to gather all the currently scarce DAV ressources and
> > > expertises into one single project.... Then CalDAV or other DAV
> > > extensions would then also easily fit in such a new TLP...
> > >
> > > My 2 cts...
> > > Stéphane
> > >
> > > At 17:31 14.12.2005, Brian Moseley wrote:
> > >> Stefano Mazzocchi wrote:
> > >>
> > >>>> personally, i have no interest in working on such a thing. i
> > >>>> wouldn't tell somebody not to do it, but i wouldn't help them either.
> > >>> Can you tell us why?
> > >>
> > >> i found the slide codebase to be extremely confusing, verging on
> > >> incomprehensible. i was unable to make heads or tails of the apis and
> > >> had only the vaguest inkling of how i might extend it for caldav.
> > >>
> > >> by contrast, the jcr-server design is relatively simple and elegant,
> > >> and the extension points are natural and obvious.
> > >>
> > >> also the slide community didn't seem to have much momentum back in
> > >> the spring of 2005. there was no defined release plan and extremely
> > >> little support on the mailing list. the documentation that existed
> > >> was sparse and often frustratingly unintelligible, so when you had
> > >> questions, you were basically screwed.
> > >>
> > >> things might have changed for the better with slide, but i'm not
> > >> optimistic. i vastly prefer the jackrabbit code and community.
> > >
> > > - -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- -
> > > www.jahia.org : The Java Unified Web Platform
> > >
> >
> > --
> > Robert r. Sanders
> > Chief Technologist
> > iPOV
> > (334) 821-5412
> > www.ipov.net
>
>
>
Re: AW: webdav server(s)
Posted by Brian Moseley <bc...@osafoundation.org>.
Daniel Florey wrote:
> It would be great to have a full featured WebDAV-stack implemented in Java
> with a simple and consistent api.
i agree, simple and consistent being keywords :)
> 3. The server implementation should be open to make it possible to add
> support specs easily. This requires a good concept of virtual resources and
> live/dead properties. But theses details can be discussed later on.
absolutely 100% agree.
> 4. Provide a single api for both local and remote repository communication.
> In case of remote repository communication of course WebDAV should be used
> as a protocol to enable communication with existing WebDAV-servers (Ms
> Exchange, SAP Netweaver, Software AG's Tamino-Server etc).
what you're describing sounds like webdav proxying. or do mean something
more?
> 5. Support for feature examination. The api should reflect the different
> levels of WebDAV support that the server provides. ACL's can be exposed in
> different ways, some specs may not be supported by certain servers. This
> should be reflected in the api.
agree.
> We are currently discussing to move Slide to TLP at the
> Slide-dev-Mailinglist. Personally I'd prefer to create a new
> webdav.apache.org TLP and start something more elegant from scratch. If
> there is a chance to combine the efforts taken in the Slide and in the
> Jackrabbit project concerning the WebDAV support, I'd be glad to support
> this effort.
so would i, as long as the effort really is from scratch and is not
simply a refactoring or reheating of slide.
we've already got a great set of building blocks with jcr-server, and my
own project has too much invested in it for me to consider putting
effort into a ground-up rebuild.
AW: webdav server(s)
Posted by Daniel Florey <da...@web.de>.
Hi folks,
this in an interesting thread.
It would be great to have a full featured WebDAV-stack implemented in Java
with a simple and consistent api.
When the Jackrabbit project started, I was little bit frustrated that people
started to reinvent the wheel instead of using simple
WebDAV-to-java-method-mapping as api. So I stuck with the Slide project even
though the codebase is really a mess and nobody really likes to work on it.
If there would be a combined effort to implement a robust WebDAV-stack, I'd
really appreciate this.
Let me summarize the goals of such a project from my point of view:
1. The big advantage of WebDAV is that users can (in theory) use existing
clients to communicate with the server. There are many clients supporting
the very basic WebDAV set, but not many using any advanced WebDAV-features
(Delta-V, DASL, ACL).
The best WebDAV-clients supporting Versioning (and this seems to be the
hardest part to implement) are subclipse and TortoiseSVN.
So my primary goal of an apache WebDAV-project would be to be interoperable
with subversion. This could also include close communication with the
subversion team and perhaps changes to make subversion more WebDAV-compliant
and discussions on the DeltaV-mailing list to incorporate extensions that
subversion introduced into the spec if necessary.
It could be part of the WebDAV-project to provide new features for the
subclipse-Plugin to support ACL, DASL, Bindings and other WebDAV-features
right out of eclipse.
This could lead to a RCP-solution to provide a robust and mature
cross-platform WebDAF-client.
2. Support of all important specs that you can find on Julian Reschke's
great webdav site:
http://www.greenbytes.com/tech/webdav
3. The server implementation should be open to make it possible to add
support specs easily. This requires a good concept of virtual resources and
live/dead properties. But theses details can be discussed later on.
4. Provide a single api for both local and remote repository communication.
In case of remote repository communication of course WebDAV should be used
as a protocol to enable communication with existing WebDAV-servers (Ms
Exchange, SAP Netweaver, Software AG's Tamino-Server etc).
5. Support for feature examination. The api should reflect the different
levels of WebDAV support that the server provides. ACL's can be exposed in
different ways, some specs may not be supported by certain servers. This
should be reflected in the api.
We are currently discussing to move Slide to TLP at the
Slide-dev-Mailinglist. Personally I'd prefer to create a new
webdav.apache.org TLP and start something more elegant from scratch. If
there is a chance to combine the efforts taken in the Slide and in the
Jackrabbit project concerning the WebDAV support, I'd be glad to support
this effort.
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: jackrabbit-dev-return-4903-daniel.florey=web.de@incubator.apache.org
> [mailto:jackrabbit-dev-return-4903-
> daniel.florey=web.de@incubator.apache.org] Im Auftrag von Robert r.
> Sanders
> Gesendet: Mittwoch, 14. Dezember 2005 20:27
> An: jackrabbit-dev@incubator.apache.org
> Betreff: Re: webdav server(s)
>
> As someone who has been monitoring both Jackrabbit and Slide lists this
> idea struck me before. If the people still working on Slide could be
> brought over to work with some of the Jackrabbit people it seems to me
> that this would be in the best interests of both communities. I don't
> know how this would be done, or wether a TLP or a subproject would be a
> better alternative. While they aren't the same (and I am not an expert
> on either) it seems obvious that there are some gains to be made by
> having a full featured WebDAV server with a JCR backend.
>
> Stéphane Croisier wrote:
> >
> > There is a thread running on right now on the Slide Dev List about
> > moving Slide to a Top Level Apache Project (TLP). Currently we are
> > using Slide as a temporary solution to store some binary files for our
> > CMS and I agree quite a lot with the conclusions of Brian... The Slide
> > project is nearly dead and without nearly any activities from
> > beginning of this year.
> >
> > So the best solution would certainly be to open a new "dav.apache.org"
> > top level project which would include a Slide 3.0 full refactoring
> > based on Jackrabbit (or whatever would be the new name of such a
> > project) and try to gather all the currently scarce DAV ressources and
> > expertises into one single project.... Then CalDAV or other DAV
> > extensions would then also easily fit in such a new TLP...
> >
> > My 2 cts...
> > Stéphane
> >
> > At 17:31 14.12.2005, Brian Moseley wrote:
> >> Stefano Mazzocchi wrote:
> >>
> >>>> personally, i have no interest in working on such a thing. i
> >>>> wouldn't tell somebody not to do it, but i wouldn't help them either.
> >>> Can you tell us why?
> >>
> >> i found the slide codebase to be extremely confusing, verging on
> >> incomprehensible. i was unable to make heads or tails of the apis and
> >> had only the vaguest inkling of how i might extend it for caldav.
> >>
> >> by contrast, the jcr-server design is relatively simple and elegant,
> >> and the extension points are natural and obvious.
> >>
> >> also the slide community didn't seem to have much momentum back in
> >> the spring of 2005. there was no defined release plan and extremely
> >> little support on the mailing list. the documentation that existed
> >> was sparse and often frustratingly unintelligible, so when you had
> >> questions, you were basically screwed.
> >>
> >> things might have changed for the better with slide, but i'm not
> >> optimistic. i vastly prefer the jackrabbit code and community.
> >
> > - -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- -
> > www.jahia.org : The Java Unified Web Platform
> >
>
> --
> Robert r. Sanders
> Chief Technologist
> iPOV
> (334) 821-5412
> www.ipov.net
Re: webdav server(s)
Posted by "Robert r. Sanders" <ro...@ipov.net>.
As someone who has been monitoring both Jackrabbit and Slide lists this
idea struck me before. If the people still working on Slide could be
brought over to work with some of the Jackrabbit people it seems to me
that this would be in the best interests of both communities. I don't
know how this would be done, or wether a TLP or a subproject would be a
better alternative. While they aren't the same (and I am not an expert
on either) it seems obvious that there are some gains to be made by
having a full featured WebDAV server with a JCR backend.
Stéphane Croisier wrote:
>
> There is a thread running on right now on the Slide Dev List about
> moving Slide to a Top Level Apache Project (TLP). Currently we are
> using Slide as a temporary solution to store some binary files for our
> CMS and I agree quite a lot with the conclusions of Brian... The Slide
> project is nearly dead and without nearly any activities from
> beginning of this year.
>
> So the best solution would certainly be to open a new "dav.apache.org"
> top level project which would include a Slide 3.0 full refactoring
> based on Jackrabbit (or whatever would be the new name of such a
> project) and try to gather all the currently scarce DAV ressources and
> expertises into one single project.... Then CalDAV or other DAV
> extensions would then also easily fit in such a new TLP...
>
> My 2 cts...
> Stéphane
>
> At 17:31 14.12.2005, Brian Moseley wrote:
>> Stefano Mazzocchi wrote:
>>
>>>> personally, i have no interest in working on such a thing. i
>>>> wouldn't tell somebody not to do it, but i wouldn't help them either.
>>> Can you tell us why?
>>
>> i found the slide codebase to be extremely confusing, verging on
>> incomprehensible. i was unable to make heads or tails of the apis and
>> had only the vaguest inkling of how i might extend it for caldav.
>>
>> by contrast, the jcr-server design is relatively simple and elegant,
>> and the extension points are natural and obvious.
>>
>> also the slide community didn't seem to have much momentum back in
>> the spring of 2005. there was no defined release plan and extremely
>> little support on the mailing list. the documentation that existed
>> was sparse and often frustratingly unintelligible, so when you had
>> questions, you were basically screwed.
>>
>> things might have changed for the better with slide, but i'm not
>> optimistic. i vastly prefer the jackrabbit code and community.
>
> - -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- -
> www.jahia.org : The Java Unified Web Platform
>
--
Robert r. Sanders
Chief Technologist
iPOV
(334) 821-5412
www.ipov.net
Re: webdav server(s)
Posted by Stéphane Croisier <sc...@jahia.com>.
There is a thread running on right now on the
Slide Dev List about moving Slide to a Top Level
Apache Project (TLP). Currently we are using
Slide as a temporary solution to store some
binary files for our CMS and I agree quite a lot
with the conclusions of Brian... The Slide
project is nearly dead and without nearly any
activities from beginning of this year.
So the best solution would certainly be to open a
new "dav.apache.org" top level project which
would include a Slide 3.0 full refactoring based
on Jackrabbit (or whatever would be the new name
of such a project) and try to gather all the
currently scarce DAV ressources and expertises
into one single project.... Then CalDAV or other
DAV extensions would then also easily fit in such a new TLP...
My 2 cts...
Stéphane
At 17:31 14.12.2005, Brian Moseley wrote:
>Stefano Mazzocchi wrote:
>
>>>personally, i have no interest in working on
>>>such a thing. i wouldn't tell somebody not to
>>>do it, but i wouldn't help them either.
>>Can you tell us why?
>
>i found the slide codebase to be extremely
>confusing, verging on incomprehensible. i was
>unable to make heads or tails of the apis and
>had only the vaguest inkling of how i might extend it for caldav.
>
>by contrast, the jcr-server design is relatively
>simple and elegant, and the extension points are natural and obvious.
>
>also the slide community didn't seem to have
>much momentum back in the spring of 2005. there
>was no defined release plan and extremely little
>support on the mailing list. the documentation
>that existed was sparse and often frustratingly
>unintelligible, so when you had questions, you were basically screwed.
>
>things might have changed for the better with
>slide, but i'm not optimistic. i vastly prefer
>the jackrabbit code and community.
- -- --- -----=[ scroisier2 at jahia dot com ]=---- --- -- -
www.jahia.org : The Java Unified Web Platform
Re: webdav server(s)
Posted by Brian Moseley <bc...@osafoundation.org>.
Stefano Mazzocchi wrote:
>> personally, i have no interest in working on such a thing. i wouldn't
>> tell somebody not to do it, but i wouldn't help them either.
>
> Can you tell us why?
i found the slide codebase to be extremely confusing,
verging on incomprehensible. i was unable to make heads or
tails of the apis and had only the vaguest inkling of how i
might extend it for caldav.
by contrast, the jcr-server design is relatively simple and
elegant, and the extension points are natural and obvious.
also the slide community didn't seem to have much momentum
back in the spring of 2005. there was no defined release
plan and extremely little support on the mailing list. the
documentation that existed was sparse and often
frustratingly unintelligible, so when you had questions, you
were basically screwed.
things might have changed for the better with slide, but i'm
not optimistic. i vastly prefer the jackrabbit code and
community.
Re: webdav server(s)
Posted by Stefano Mazzocchi <st...@apache.org>.
Brian Moseley wrote:
> Cyrus Daboo wrote:
>
>> Why not just create a jcr 'store' implementation for Slide?
>
> personally, i have no interest in working on such a thing. i wouldn't
> tell somebody not to do it, but i wouldn't help them either.
Can you tell us why?
--
Stefano.
Re: webdav server(s)
Posted by Brian Moseley <bc...@osafoundation.org>.
Cyrus Daboo wrote:
> Why not just create a jcr 'store' implementation for Slide?
personally, i have no interest in working on such a thing. i wouldn't
tell somebody not to do it, but i wouldn't help them either.
Re: webdav server(s)
Posted by Cyrus Daboo <cy...@daboo.name>.
Hi Roy,
--On December 13, 2005 6:12:08 PM -0800 "Roy T. Fielding"
<fi...@gbiv.com> wrote:
> I think I understand now the disjoint thoughts on how the jcr-server
> should be designed. The existing jcr-server is a webdav view of a
> JCR repository, whereas it seems Brian is looking for a general
> webdav server that happens to use JCR as its storage interface.
> The reason for the confusion is because JCR and WebDAV do not share
> the same hierarchical models -- either one can emulate the other,
> but they are not the same.
>
> What I suggest is that we start a separate contrib project for a
> general webdav server implemented using JCR and see how much of
> the code can be shared between the two, gradually merging them
> together until we reach a point where the two are (hopefully)
> distinguishable only by configuration files. What do you think
> of that as a plan?
Why not just create a jcr 'store' implementation for Slide?
--
Cyrus Daboo
Re: webdav server(s)
Posted by Angela Schreiber <an...@day.com>.
Brian Moseley wrote:
> Angela Schreiber wrote:
>> - DavResource
>> - DavResourceFactory
>> - DavResourceLocator
>> - DavResourceLocatorFactory
>> plus generic configuration (there is no such thing in the
>> library) to make the general implementation suitable for all
>> kind of JSR170 implementations.
> also IOManager and IOHandler
sure... they go with the configuration from my point of
view. the nodes/nodetypes you define/allow for the various
resource types call for an appropriate import/export
handling....just in case you want to use the stuff
present in the server/io-package, which is not forced
by the webdav library.
the current simple config does neither force nor assert,
that the resource type configuration matches the import/
export.
regards
angela
Re: webdav server(s)
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> perhaps i'm missing some fundamental things (blind because
> i spent quite some time on the jcr-server contrib). but from
> my point of view, it's the general implementation of the
> following interfaces that is missing:
>
> - DavResource
> - DavResourceFactory
> - DavResourceLocator
> - DavResourceLocator
>
> plus generic configuration (there is no such thing in the
> library) to make the general implementation suitable for all
> kind of JSR170 implementations.
also IOManager and IOHandler, and potentially
DavSessionProvider as well.
Re: webdav server(s)
Posted by Angela Schreiber <an...@day.com>.
hi roy
thanks for your summary. just let my address two things.
please apologize if this is completely redundant and totally
clear to everybody...
at the end i'd like to list the common parts from my
point of view.
Roy T. Fielding wrote:
> I think I understand now the disjoint thoughts on how the jcr-server
> should be designed. The existing jcr-server is a webdav view of a
> JCR repository,
this is correct for the "jcr-server/server" project, which contains
2 separate views to a JSR170 repository:
- simple server ('simple'):
provide a human readable ('filesystem') view to the jcr-repository.
one very easy example was to map 'nt:file' to non-collections
and anything else to collections.
- remoting server ('jcr'):
using webdav as transport layer for the remoting of the JSR170 api.
the reason for this was, that - from our point of view - webdav
is about 'collections' and their 'members' and not about files
and folders.
> whereas it seems Brian is looking for a general
> webdav server that happens to use JCR as its storage interface.
that's what we designed the "jcr-server/webdav" (the webdav library)
for. provide all the webdav stuff that is not related to JSR170.
except for 3 methods there is nothing JSR170 related within those
interfaces (and classes).
but yes, there is no general implementation for the DavResource
and related interfaces.
> What I suggest is that we start a separate contrib project for a
> general webdav server implemented using JCR and see how much of
> the code can be shared between the two, gradually merging them
> together until we reach a point where the two are (hopefully)
> distinguishable only by configuration files. What do you think
> of that as a plan?
thanks. sounds good to me.
i see the following common parts:
- jcr-server/webdav project ('dav library')
- jcr-server/server/[...]/AbstractWebdavServlet
- jcr-server/webapp/ except for 2 subclasses of AbstractWebdavServlet
in addition:
maybe the jcr-server/webapp/[...]/SimpleWebdavServlet could
partially be reused (but maybe brian has some additional stuff).
perhaps i'm missing some fundamental things (blind because
i spent quite some time on the jcr-server contrib). but from
my point of view, it's the general implementation of the
following interfaces that is missing:
- DavResource
- DavResourceFactory
- DavResourceLocator
- DavResourceLocator
plus generic configuration (there is no such thing in the
library) to make the general implementation suitable for all
kind of JSR170 implementations.
> ....Roy
kind regards
angela
webdav server(s)
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
I think I understand now the disjoint thoughts on how the jcr-server
should be designed. The existing jcr-server is a webdav view of a
JCR repository, whereas it seems Brian is looking for a general
webdav server that happens to use JCR as its storage interface.
The reason for the confusion is because JCR and WebDAV do not share
the same hierarchical models -- either one can emulate the other,
but they are not the same.
What I suggest is that we start a separate contrib project for a
general webdav server implemented using JCR and see how much of
the code can be shared between the two, gradually merging them
together until we reach a point where the two are (hopefully)
distinguishable only by configuration files. What do you think
of that as a plan?
....Roy
Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> here we go. that's the same discussion we had with the
> 'protected'. i'm talking about a 'simple' webdav server
> and you pretend its a 'abstract concrete implementation',
> which it definitely isn't.
acknowledged.
> and what about nt:unstructured? the most generic nodetype
> you can even think of?
what about it? i fail to see why somebody trying to implement a
persistence mechanism for the webdav protocol would care about a data
type that is not "collection", "resource", or some specialization of
either of those things.
> and what means highly probable?
it means "very likely". webdav is for storing resources in collections.
nt:folder and nt:file are natural fits for this job. nt:unstructured is not.
> again you are just making an assumption. in my usecase (CRX) there
> are just 2 nodetypes (or actually its only one) that should be
> displayed as non-collection resource and compared to it
> there is a huge amount of nodetypes that should be displayed
> as collections (e.g. remove the filter....). your needs are
> maybe/probably different...
wow. okay. i can't imagine your use case. perhaps you could explain it
sometime. maybe that would help me stop making assumptions.
> and there is yet another twist to the story: the
> collection/non-collection part of the configuration is
> just one part. you must also make sure that your import/export
> can handle the collection/non-collection nodes. and this
> should work for any jsr170 impl? hm.
sure, why not? i have specified a resource configuration (you saw it
before), and i have written custom node type definitions
(dav:collection, dav:resource, etc) and import/export handlers to match.
they depend on the repository supporting nt:file and nt:folder, but
that's it. and if i realized i was in a world where no jcr
implementations supported nt:file and nt:folder, i could get rid of
those and create my own custom versions that would be guaranteed to work
anywhere. so what's the problem?
> if i start thinking about this, i realize that your are
> really wrong, pretending that the 'simple' server is
> 'abstract concrete implemenation'.
>
> if i wanted to such a thing, i would have choosen a different
> implementation. and - surprise - i would have choosen
> a different name. but i disagree that we can make the simple
> server the magic-solution you are looking for, by adding
> a lot of project specific ifs and helper methods and 'protected'
> modifiers.
to some extent that is a fair criticism. when i saw "simple server" and
"jcr server", i did not take "simple" to mean "does the least amount
possible". i saw it as a straightforward alternative to slide that would
give us an out of the box webdav server that could be easily and simply
extended via some subclassing and reconfiguring. it has taken me a long
time to understand that was not your intention.
> i guess, we are just talking about different things. i'm
> consistently reconsidering the webdav library, while evaluating the
> various enhancement request, for i think enhancements will
> show the weeknesses of the design. and i have the impression
> that you just want the simple server to be suitable for
> your project but claim that with this changes we will have
> the magic-solution.
you know, i don't appreciate the attitude you are showing in the last
few messages. i've never attacked you or your design. in fact, i've
praised jcr-server highly to my colleagues as part of the reason that
i'm using jcr in my project. so i can do without your snarky
"magic-solution" comments, thanks.
i guess my problem was thinking that you wanted the simple server to
function as a drop-in replacement for slide or mod_dav. i know that you
have tried to explain things to me several times, but i never understood
what you were saying until we got down to details in the last several days.
i can't imagine i'm the only person out there who would like a webdav
server built on top of jcr, portable to many/all repository
implementations, with out-of-the-box support for:
* all of the live properties defined by rfc 2518 (the simple server
doesn't allow PROPPATCHing of displayname or getcontentlanguage)
* dead properties (because the simple server is locked into nt:file
and nt:folder, clients cannot define arbitrary properties on resources
and expect the server to store them)
* common, useful webdav extensions like acl, quota, tickets, and many
others
yes, i've implemented most of this stuff in cosmo, but don't see any of
it as specific to cosmo. i think that full, powerful webdav on top of
jcr should be a commodity that people don't have to download cosmo with
all of its extra features to get. just like people don't have to buy CRX
or whatever to get themselves a nice content repository.
maybe this should be another jcr-server implementation, or jackrabbit
contrib project, or apache project, or jackrabbit contrib project. i
dunno. i don't have the energy or interest to establish such a project,
but i'd certainly contribute as much from cosmo as would be useful.
Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Posted by Angela Schreiber <an...@day.com>.
hi brian
Brian Moseley wrote:
> Angela Schreiber wrote:
>> you want a config that is good enough for any jsr170 implementation?
> that's the goal, yes.
here we go. that's the same discussion we had with the
'protected'. i'm talking about a 'simple' webdav server
and you pretend its a 'abstract concrete implementation',
which it definitely isn't.
> it's highly probable
> that every jsr170 implemetnation one would consider using for a
> scalable, performant, featureful internet server would implement
> nt:folder and nt:file.
and what about nt:unstructured? the most generic nodetype
you can even think of?
and what means highly probable?
you make assumptions... and you just pretend, that an arbitrary
jsr170 implementation would be such that it justifies your
hardcoded check.
>> your argument is - from my point of view contradictory.
>> with an arbitrary implemenation of jsr170 the list of
>> collection-nodetypes could equally grow to a theoretically
>> huge amount of nodetypes.
> that seems much less likely. the wide variety of types of resources
> stored in a webdav server dwarfs the types of collections that exists
> (precisely two in webdav+caldav).
again you are just making an assumption. in my usecase (CRX) there
are just 2 nodetypes (or actually its only one) that should be
displayed as non-collection resource and compared to it
there is a huge amount of nodetypes that should be displayed
as collections (e.g. remove the filter....). your needs are
maybe/probably different...
and there is yet another twist to the story: the
collection/non-collection part of the configuration is
just one part. you must also make sure that your import/export
can handle the collection/non-collection nodes. and this
should work for any jsr170 impl? hm.
if i start thinking about this, i realize that your are
really wrong, pretending that the 'simple' server is
'abstract concrete implemenation'.
if i wanted to such a thing, i would have choosen a different
implementation. and - surprise - i would have choosen
a different name. but i disagree that we can make the simple
server the magic-solution you are looking for, by adding
a lot of project specific ifs and helper methods and 'protected'
modifiers.
i guess, we are just talking about different things. i'm
consistently reconsidering the webdav library, while evaluating the
various enhancement request, for i think enhancements will
show the weeknesses of the design. and i have the impression
that you just want the simple server to be suitable for
your project but claim that with this changes we will have
the magic-solution.
i think we are arguing about different things.
kind regards
angela
Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> you want a config that is good enough for any jsr170 implementation?
that's the goal, yes.
> actually, i thought this exactly what we have the config for:
> make it easy to redefine the set of nodetypes that either
> define collections or non-collections. otherwise we could have
> left it hardcoded in the resource implemenation.
>
> your config example - even with the hardcoded check for the root
> node in the configuration - would not provide a useful
> result when used with CRX. and CRX is pretty close to
> jackrabbit.
what would i have to change to work with CRX?
> what i want to say is: i'm pretty sure, that you will have to
> adjust your configuration a little bit, when running your cosmo
> project on jsr170 implementation selected by change (see above
> for the initial reason to built the ResourceConfig).
it's a shame that i can't drop the cosmo webapp into an
application server and use it untouched no matter what
repository implementation happens to be provided as a
resource by the app server. don't you agree that's a worthy
goal?
> please note, that any nodetype defined by jsr170 is optional
> except for nt:base (section 6.7.22 in the specification).
> you cannot rely on a jsr170 implementation providing the
> nt:folder nodetype... thus your config is not safe for
> any arbitrary jsr170 impl.
heh. there are varying degrees of safety, angela. it's
highly probable that every jsr170 implemetnation one would
consider using for a scalable, performant, featureful
internet server would implement nt:folder and nt:file.
lacking any guidance from the spec whatsoever, it's much
less probable that several implemenations will choose the
same node type for their root node.
> for this reason i think its feasible to adjust the config,
> when running on different implementation. for your example
> (perhaps running on jackrabbit) i would suggest to add
> 'nt:unstructured' (which is extended by the jackrabbit
> internal nodetype rep:root) to the set of nodes that
> should be displayed as collection.
thanks for the suggestion. i guess instead of being able to
rely on one standard root node type i'll have to test drive
every jcr implementation i can find and make sure they are
all accounted for in my resource config.
> your argument is - from my point of view contradictory.
> with an arbitrary implemenation of jsr170 the list of
> collection-nodetypes could equally grow to a theoretically
> huge amount of nodetypes.
that seems much less likely. the wide variety of types of
resources stored in a webdav server dwarfs the types of
collections that exists (precisely two in webdav+caldav).
Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Posted by Angela Schreiber <an...@day.com>.
hi brian
Brian Moseley wrote:
> Angela Schreiber wrote:
> not having a guaranteed node type for the root node, i can't specify one
> in the <collection/> section of the resource config. the one defined by
> jackrabbit isn't good enough, since i want cosmo to remain as portable
> as possible to other jcr implementations.
you want a config that is good enough for any jsr170 implementation?
actually, i thought this exactly what we have the config for:
make it easy to redefine the set of nodetypes that either
define collections or non-collections. otherwise we could have
left it hardcoded in the resource implemenation.
your config example - even with the hardcoded check for the root
node in the configuration - would not provide a useful
result when used with CRX. and CRX is pretty close to
jackrabbit.
what i want to say is: i'm pretty sure, that you will have to
adjust your configuration a little bit, when running your cosmo
project on jsr170 implementation selected by change (see above
for the initial reason to built the ResourceConfig).
please note, that any nodetype defined by jsr170 is optional
except for nt:base (section 6.7.22 in the specification).
you cannot rely on a jsr170 implementation providing the
nt:folder nodetype... thus your config is not safe for
any arbitrary jsr170 impl.
for this reason i think its feasible to adjust the config,
when running on different implementation. for your example
(perhaps running on jackrabbit) i would suggest to add
'nt:unstructured' (which is extended by the jackrabbit
internal nodetype rep:root) to the set of nodes that
should be displayed as collection.
> also, i do not want to take the opposite route and specify every
> nodetype that is not a collection, because that could theoretically be a
> huge and arbitrarily growing list of node types.
yes, that's why we have both options: either define the
collections or the non-collections.
your argument is - from my point of view contradictory.
with an arbitrary implemenation of jsr170 the list of
collection-nodetypes could equally grow to a theoretically
huge amount of nodetypes.
kind regards
angela
Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> could you please elaborate, what exactly made you struggle with
> a ResourceConfiguration, that does not have the hardcoded check
> for the root collection? your checkin states what you did (which
> is obvious from the diff) and not why.
not having a guaranteed node type for the root node, i can't
specify one in the <collection/> section of the resource
config. the one defined by jackrabbit isn't good enough,
since i want cosmo to remain as portable as possible to
other jcr implementations.
also, i do not want to take the opposite route and specify
every nodetype that is not a collection, because that could
theoretically be a huge and arbitrarily growing list of node
types.
i understand your point about the root node potentially
being interpreted as a non-collection, but in practice i
can't imagine why somebody would do that. i think the common
case should be the one defaulted to by the code, and the
corner case (treating the root node as a non-collection)
should be the one that requires additional configuration.
regardless of that, can you suggest another way to have the
root node treated as a collection?
for reference, here is my resource config:
<config>
<iomanager>
<class name="org.osaf.cosmo.io.CosmoIOManager"/>
</iomanager>
<collection>
<nodetypes>
<nodetype>nt:folder</nodetype>
</nodetypes>
</collection>
<filter>
<class
name="org.apache.jackrabbit.webdav.simple.DefaultResourceFilter"/>
<namespaces>
<prefix>rep</prefix>
<prefix>jcr</prefix>
<prefix>icalendar</prefix>
<prefix>ticket</prefix>
<prefix>xml</prefix>
</namespaces>
</filter>
</config>
Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Posted by Angela Schreiber <an...@day.com>.
hi brian
>> i'm not seeing in the jcr spec where the node type of the root node is
>> defined. if that's defined in the spec and i just missed it, let me
>> know so that i can add it to the list of collection node types in my
>> resource config.
the spec states:
"Which NodeType [i.e. Primary NodeType] is returned when this method
[i.e. getPrimaryNodeType()] is called on the root node of a workspace is
up to the implementation, though the returned type must, of course, be
consistent with the child nodes and properties of the root node."
The jackrabbit reference implementation of the JSR170 api defines
a separate internal nodetype for the root node: "rep:root"
see:
jackrabbit\src\main\java\org\apache\jackrabbit\core\nodetype\builtin_nodetypes.xml
since the specification does not define a particular nodetype
for the root node, it would be totally legal (though questionable)
to write an implemenation that defines the root node to be
nt:base or nt:file. and likewise its legal to add a mixin to
the root node... e.g. a special mixin type ("mix:NeverDavCollection").
My point is: having a configuration that defines the resourcetype
from a given dav-resource by a nodes nodetype (this could even be
a mixin that was added to the node), then this rule should be
applied for the root node as well. if i add my "mix:NeverDavCollection"
mixin type to the root node and try to circument with an extra
if-statement, that this results in a single non-collection resource
at the root level, then i'm going to hide my own, incomplete nodetype
design (or strange usage of the resourceconfig) behind a hardcoded
statement in the code.
could you please elaborate, what exactly made you struggle with
a ResourceConfiguration, that does not have the hardcoded check
for the root collection? your checkin states what you did (which
is obvious from the diff) and not why.
regards
angela
Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Posted by Brian Moseley <bc...@osafoundation.org>.
Brian Moseley wrote:
>> now to your change: you define that the root node
>> should always be a collection. of cause this is the
>> desired result, because otherwise you won't get huge
>> benefit out of your webdav.
>>
>> but i don't agree that it's correct to hardcode it
>> into the ResourceConfig. if it turns out that the config
>> as is does provide enough flexibility and you run
>> into problems (thus your configuration resulted in a
>> non-collection root), i'd say that the way the config was
>> designed is wrong and should be reviewed.
>>
>> maybe you can explain, what kind of troubles you had
>> with the configuration as is?
>
> i'm not seeing in the jcr spec where the node type of the root node is
> defined. if that's defined in the spec and i just missed it, let me know
> so that i can add it to the list of collection node types in my resource
> config.
angela, thoughts?
Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> please apologize, but i start feeling a little embarrassed.
this is what happens when a new person begins working on
somebody else's large body of existing code. it's an
expected process of transferring knowledge that is not
already written into the code via comments, design docs,
etc. it doesn't bother me :)
> now to your change: you define that the root node
> should always be a collection. of cause this is the
> desired result, because otherwise you won't get huge
> benefit out of your webdav.
>
> but i don't agree that it's correct to hardcode it
> into the ResourceConfig. if it turns out that the config
> as is does provide enough flexibility and you run
> into problems (thus your configuration resulted in a
> non-collection root), i'd say that the way the config was
> designed is wrong and should be reviewed.
>
> maybe you can explain, what kind of troubles you had
> with the configuration as is?
i'm not seeing in the jcr spec where the node type of the
root node is defined. if that's defined in the spec and i
just missed it, let me know so that i can add it to the list
of collection node types in my resource config.