jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Moseley <...@osafoundation.org>
Subject Re: svn commit: r354818 - /incubator/jackrabbit/trunk/contrib/jcr-server/server/src/java/org/apache/jackrabbit/webdav/simple/ResourceConfig.java
Date Tue, 13 Dec 2005 18:45:07 GMT
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.

Mime
View raw message