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 16:37:38 GMT
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).


Mime
View raw message