Andy Depue wrote:
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."
i haven't read it either. in fact, this is the first i've heard of it. but if it is what it sounds like, then i'm all for giving it a whirl.
Client -> JSR-170 (Jackrabbit) -> (network) -> WebDAV servlet -> JSR-170 (store)
this is sort of close to how i've envisioned my project (a calendar server). here are pictures that hopefully will illustrate what i want:
legend:
<--> == over the internet
<==> == over the local network
| == jsr 170 or other content store api1) single host server deployment
dav client <--> webdav adapter | content store web client <--> web ui | content store
2) multiple host server deployment
dav client <--> webdav adapter | content store web client <--> web ui <==> webdav adapter | content store
now, if jackrabbit will let me use jsr 170 in scenario #2 to do webdav from my web ui across my network, i'll be ecstatic. i'm not really interested in writing webdav dao implementations for a calendar ui :)
in any event, it seems pretty clear to me that the content store api (jsr 170 or custom) needs to be able to be used directly by applications as well as by the webdav adapter.
it also seems clear that if jsr 170 is sufficient as our own content store api, it should be our first choice, since other people are putting in work to implement content stores for it. best to spread effort among as many people as possible.
if jsr 170 turns out to not be good enough for whatever reason, then we come up with our own custom api, and perhaps we put a jsr 170 adapter on top of it that is a peer of the webdav adapter.
[snipping a bunch of discussion in which you come to the conclusion that i just worked out for myself above]
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.
i'm pretty sure that jsr 170 will give us what we need to do caldav, which mainly deals with the content itself. it defines verbs for accessing calendars and freebusy time, for instance, as opposed to arbitrary content. there are definitely new methods and new report types, but i don't see them levying extensive additional requirements on the content store.
certainly designing a webdav adapter that can be easily extended to add additional methods is a must. it is likely that more protocols will be designed to layer on top of webdav. i also think that an events subsystem like the one in slide would be of great benefit. people are always going to come up with bizarre customizations, and building something flexible in from the beginning will be the best way to address those issues.
PostgreSQL sounds great to me, since that is what we use. :)
what specific postgres code do you have? i tend to favor mysql myself, and i'm using hsqldb right now as an embedded option for my project, so i'd prefer that any rdbms access be done through an orm layer of some sort that can abstract away the details. hibernate being my orm tool of choice :)
Oh, and what about coding style? Do we care? If so, what do we want to standardize on?
how about starting with whatever java doing style apache enforces, if any?
------------------------------------------------------- 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
