Acegi/Spring + Slide

So essentially Cosmo is adding additional DAV protocols on
top of the  
"simple" jcr-server implementation? As in a
MKCALENDAR message to  
Cosmo gets translated to MKCOL and sent to the jcr-server?

I'm actually wondering if my project might be better served
by  
directly using the "simple" jcr-server, as you
did, and supporting  
the transition of that code into a full-fledged WebDAV
server. The  
way we've conceived the digital library aspect of the
project means  
the users don't get to directly control filenames, or
resource  
locations within the repository. So as long as my web-app
has full  
access to the repository (using whatever interface is most  
efficient), what I really need is a WebDAV server that
supports GET  
(and maybe PROPFIND) and defers user authentication to
Whisper's back  
end (Acegi). Do you have any thoughts on the relative
difficulty of  
this using Cosmo vs. Jackrabbit directly?

Mark

On Feb 10, 2006, at 10:56 AM, Brian Moseley wrote:

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

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

On 2/10/06, Mark Slater <listshumanesoftware.com>
wrote:
> So essentially Cosmo is adding additional DAV protocols
on top of the
> "simple" jcr-server implementation? As in a
MKCALENDAR message to
> Cosmo gets translated to MKCOL and sent to the
jcr-server?

yes to the first question, not quite to the second. cosmo
handles
MKCALENDAR by creating a corresponding node of a specific
type
(calendar:calendar i believe) in the jcr repository and
setting some
caldav-specific properties on that node. jcr-server handles
MKCOL
similarly but with a different node type.

> I'm actually wondering if my project might be better
served by
> directly using the "simple" jcr-server, as
you did, and supporting
> the transition of that code into a full-fledged WebDAV
server. The
> way we've conceived the digital library aspect of the
project means
> the users don't get to directly control filenames, or
resource
> locations within the repository. So as long as my
web-app has full
> access to the repository (using whatever interface is
most
> efficient), what I really need is a WebDAV server that
supports GET
> (and maybe PROPFIND) and defers user authentication to
Whisper's back
> end (Acegi). Do you have any thoughts on the relative
difficulty of
> this using Cosmo vs. Jackrabbit directly?

using jcr-server directly, you'd have the same issues
discussed
earlier in the thread re integration with your user database
and
implementing acl support, but you'd also have the
additional burden of
integrating acegi security yourself.

on the other hand, cosmo has acegi security built in, has (i
think) a
pretty simple extension point for integrating with your user
db, and
is waiting for somebody to have the time and interest to add
acl
support. cosmo also represents a lot of time spent
understanding the
nuances of jcr-server which you'd have to put in yourself
to get your
app working with it. and of course, should you want to add
support for
calendaring (and eventually scheduling, tasks, contacts,
etc) to your
project, you'd get all that for free.

i hope that we do eventually build up some momentum for an
asf
"full-stack" jcr-backed dav server. since i
think cosmo is proceeding
further in this direction than any other project, we're
probably going
to be the ones that jumpstart any such effort at apache by
donating
code to them. so should you choose to use cosmo and put some
work into
an acl backend, that work would be likely to end up in
jackrabbit or
somewhere else in the asf eventually anyway. if that's any
motivation
for you 
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo