[Cosmo] Re: Acegi/Spring + Slide
bcm at osafoundation.org
Fri Feb 10 10:56:22 PST 2006
On 2/10/06, Mark Slater <mslater at soe.ucsc.edu> wrote:
> There's two important things I'm looking for in a WebDAV server:
> - The ability to integrate its security system (usernames/paswords
> and ACLs) with my existing back end.
cosmo doesn't have a concept of acls yet, though that's one of the
highest priority items on the todo list.
also, cosmo has its own set of user accounts, so you'd either need to
sync those with your own backend (using cmp would help with that) or
provide your own implementation of cosmo's UserDao interface that
works against your backend. the only stumbling block i see to doing
the latter is assumptions about the format of the attributes of a user
- min/max length, syntax, etc - but i'd like for those things to
eventually be policy-based anyway, so maybe this is an opportunity to
finally push on that idea.
> - Support for the WebDAV BIND protocol
cosmo doesn't support this dav extension, but i'd have no objection to
this might be a good time to mention that there has been some
discussion of forming a new apache project (perhaps a subproject of
jackrabbit) that builds upon jcr-server's "simple" webdav
implementation to add full support for webdav classes 1 and 2 and
various extensions such as acl, quota, tickets, and perhaps caldav and
carddav as well. a new alternative to slide based on jcr. there hasn't
been any movement on this idea yet, mainly because i've been waiting
to get cosmo 0.3 out the door before looking at what cosmo code we
could potentially transfer to that project.
> The calendaring support in Cosmo could be very useful down the road,
> but probably not until after I'm done with my Ph.D. I did notice that
> the Slide committers haven't been around much for the last 6 or 7
> months, and that does concern me; I wouldn't want to get stuck using
> a project that suddenly dies out.
i haven't looked at slide in 9 or 10 months, but my perception then
was exactly the same - no real movement on the code for several
months, no clear release plan, little or no community involvement. to
see that the trend has continued through to 2006 helps confirm my
decision to use jackrabbit and jcr-server instead.
> One thing I'm not clear on is how Cosmo and Jackrabbit interact. It
> would seem to me that Cosmo (a WebDAV server) would serve as a back
> end for Jackrabbit (a Java API into a content repository)... your
> email suggests that Cosmo is using Jackrabbit as a backend... so
> WebDAV -> JSR170 -> WebDAV?
jcr was designed with remote access in mind, and one of the possible
remoting protocols mentioned in the spec is webdav.
there are two main conceptual models (not to be confused with the
deployment models described on the jackrabbit web site):
1) webdav client -> webdav server -> jcr api -> repository
2) jcr application -> jcr api (server side) -> webdav remoting -> jcr
api (server side) -> repository
and of course you can combine the two:
3) webdav client -> webdav server -> jcr api (client side) -> webdav
remoting -> jcr api (server side) -> repository
today snarf (our integrated server bundle) uses the first model,
making an embedded jackrabbit repository available to cosmo as a j2ee
resource. one could certainly replace that with a remote jackrabbit
repository (speaking rmi or webdav) without affecting cosmo, tho we
haven't done any experiments with that configuration yet.
> PS. You may be interested to know that Jim Whitehead is my Ph.D.
small world :)
More information about the Cosmo