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.
