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).
