Acegi/Spring + Slide

On 2/10/06, Mark Slater <mslatersoe.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
adding it.

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

small world 
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo