Ben,
It's great to see you mention JSR 170! I was just going to recommend that
we utilize JSR-170 before reading your message. Now, I haven't read over
JSR-170 myself yet, but am assuming that it is what it claims to be, "a
standard API to access content repositories in Java 2 independently of
implementation." Specifically, I was toying in my own mind whether the
content repository store should just be an implementation of JSR-170 (which
is what you mention as well). That would end up looking something like this:
Acegi security auth -> WebDAV servlet -> JSR-170
In other words, the WebDAV servlet will be using JSR-170 API to access the
content repository. BTW, when I say "WebDAV servlet", I'm referring to the
whole picture (servlet+controller). The WebDAV servlet becomes, in effect, an
adapter between the WebDAV protocol and JSR-170 API. We could then plug any
JSR-170 implementation into the picture, including our own.
The only concern I would have is if JSR-170 ends up being too unwieldy to
implement or it ends up being so geared toward client usage that it does not
accommodate the needs of a server side WebDAV front. I won't know the answer
until I read the spec.
Of course, there are other ways to approach utilization of JSR-170:
+----------------+
| WebDAV servlet |----+
+----------------+ |
+---> Content store service API -> Spring based DAO
+----------------+ |
| JSR-170 API |----+
+----------------+
Here, JSR-170 is at the same level as WebDAV (you can access our store
either by JSR-170 or by WebDAV).
WebDAV servlet -> Content store API -> JSR-170
Here, JSR-170 is the "DAO" and the content store API serves simply to adapt
it for easy usage by the WebDAV servlet. At first glance, I'm not real fond
of this approach, so, going back to our first picture:
+-------------+ +---------------+
+-->| DAO adapter |-->| DAO interface |
| +-------------+ +---------------+
WebDAV servlet -> JSR-170 ---+
| +-------------------------------+
+-->| Actual JSR-170 implementation |
+-------------------------------+
Here, the WebDAV servlet accesses the repository via JSR-170, and we supply
an implementation that will either delegate to an actual JSR-170 impl or use
an adapter that allows a developer to implement a store via an
easier-to-implement DAO interface (that is, if we determine JSR-170 to be a
little harsh to implement). In this case, JSR-170 has become our "service"
interface.
What's interesting to think about is that (I believe) Jackrabbit is creating
an implementation of JSR-170 to access WebDAV. In other words, the client
who is accessing the repository will use JSR-170, and that JSR-170
implementation will use the WebDAV protocol. So, you can end up with
something like this:
Client -> JSR-170 (Jackrabbit) -> (network) -> WebDAV servlet -> JSR-170
(store)
This may seem rather indirect, but it becomes valuable, as in our case, when
you have rich internet clients (written in Java, launched via JWS) that need
to access the document repository. When developing RiA you really try to
keep everything on HTTP/HTTPS to avoid firewall issues, which makes WebDAV
very attractive. Plus, the customer can access the repository independently
of our RiA via their own WebDAV aware products. On the other side of the
coin, this approach would also provide the choice to directly embed and
co-locate the content repository. The client code still uses JSR-170, only
instead of using the WebDAV implementation (Jackrabbit), we hand it the store
implementation, completely cutting WebDAV out of the picture. I can see this
approach being useful for server side applications:
Client code -> JSR-170 (store)
One side effect of this approach is that the WebDAV servlet becomes very
independent. It is no longer tied to our specific store/service/repository
API. This seems to suggest a very logical and clean project break between
the WebDAV servlet and the JSR-170 implementation. Maybe splitting this up
into subprojects is a good idea? I could see a WebDAV servlet that is simply
a front for JSR-170 becoming attractive to a much larger audience. For
example, there might be Magnolia users out there wishing for WebDAV (I don't
recall that it already has WebDAV?)...
Finally, how to handle extensions like CalDAV? Not that we are planning on
implementing CalDAV up front, but just that we don't want to completely lock
ourselves into something like JSR-170 if it wouldn't permit a future addition
such as a CalDAV module. I'm at a loss here, because I am not familiar with
either the CalDAV spec or the JSR-170 spec - but if JSR-170 does not provide
the functionality needed by CalDAV, then we need to be sure to design the
WebDAV controller in such a way that it is easily extensible beyond JSR-170.
For example, the Controller could dispatch to Methods (as in, MKCOL,
PROPPATCH, etc), which are free to implement themselves however they see fit,
though most of them will happen to use the JSR-170 API. But even that isn't
quite going to cut it... hmm.. some discussion might be necessary here.
PostgreSQL sounds great to me, since that is what we use. :)
Oh, and what about coding style? Do we care? If so, what do we want to
standardize on?
Well, I'm going to be traveling this weekend and will be out of touch with
the list. However, I will be taking a big stack of specs with me to read up
on (WebDAV, JSR-170, etc). :)
- Andy
On Thursday 03 March 2005 08:54 pm, Ben Alex wrote:
> Dear Acegi WebDAV Developers
>
> First of all, WELCOME! It’s good to be working with you all on
> developing a WebDAV server implementation based around Spring + Acegi
> Security.
>
> In addition to myself, on the team we currently have Andy Depue, Brian
> Moseley, Carlos Sanchez and Luke Taylor. Each of you have been added to
> the acegiwebdav-developer and acegiwebdav-cvs mailing lists. You each
> have CVS commit permissions to the source tree (see
> http://sourceforge.net/projects/acegiwebdav/). I’ve setup for
> acegiwebdav-developer to be archived at mail-archive.com, and applied
> for a newsgroup at Gmane for the same list.
>
> The general scope of this project is to provide an interface-driven,
> RFC-compliant WebDAV server that is managed by a Spring IoC container
> and uses Acegi Security for AAA. The WebDAV server will probably
> comprise these layers:
>
> * Standard WebDAV Client
> * Dispatcher (based on HTTP type: GET, PUT, MKCOL etc)
> * Controller (converts XML request to strictly typed POJOs or method args)
> * Services and (possibly integrated or separately layered) Persistence
>
> At the core of any WebDAV server is a content repository, and JSR 170
> has progressed well in this area. The reference implementation is called
> Jackrabbit and is undergoing active development at
> http://incubator.apache.org/projects/jackrabbit.html. It’s already used
> in Magnolia (http://www.magnolia.info), suggesting it might be mature
> enough for our use as well. In view of JSR 170, there are two possible
> approaches to the services / persistence layer design.
>
> The first option would be to take a long-term view and design solely for
> JSR 170 compliant implementations. As such our services layer interface
> contract would define methods very similar to JSR 170 interfaces, or
> indeed we could have the Controllers use JSR 170 interfaces directly.
>
> The second option would be to use an interface contract solely based on
> our application’s specific needs: a repository to store WebDAV content.
> As such the interface would provide a simpler set of content repository
> methods, as needed by Controllers to perform their functions. Two
> concrete implementations of such an interface would ultimately be
> developed. One would be a JSR 170 compatibility implementation, which
> would represent a veneer of workflow code that calls JSR 170
> implementations. The second implementation would use Spring’s
> stock-standard, layered services and DAO architecture. Whilst this
> option offers the benefits of both worlds (JSR 170 plus flexibility for
> non-JSR 170 approaches), the option would result in many overlapping
> interfaces and it’s inevitable that this will prove a maintenance issue
> as the JSR 170 implementations mature and become mainstream.
>
> I already have some code based on Postgres. We could consider using that
> code and writing an implementation of JSR 170 based around Spring +
> Acegi Security + pluggable DAOs, with an initial focus perhaps on
> Postgres-specific DAOs. Would you be happy with Postgres as the
> reference DB for this project? This would probably also attract people
> interested in customizing their JSR 170 implementations using IoC, as
> well as their WebDAV servers. This is of course assuming Jackrabbit is
> not mature or flexible enough to use outright, which is obviously very
> much preferred from a number of perspectives.
>
> The other architectural question to resolve at this point is whether or
> not to use Spring MVC to dispatch requests to controllers. The main
> WebDAV RFC, number 2518, can be found at
> http://greenbytes.de/tech/webdav/ (along with many other WebDAV-related
> RFCs).
>
> On the project source code layout matter, do you think we need subprojects?
>
> I look forward to your comments on the above, and working with you on
> this project.
>
> Cheers
> Ben
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Acegiwebdav-developer mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/acegiwebdav-developer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Acegiwebdav-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegiwebdav-developer
