----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 2:30 AM Subject: Re: proposals/wvcm [was: RE: Licence for slide 2.0b]
> > On 6 Feb 2004, at 12:44, Nevermann, Dr., Peter wrote: > > >> 1) Many files under ./proposals/wvcm and proposals/jcrri have > >> not copyright > >> message attached at all. Are they somehow special since they are > >> related to the JCP? Otherwise which year should be used for the > >> copyright? > > > > The sources under proposals/wvcm without copyright header are exactly > > the interfaces provided by the JSR-147 EG (javax.wvcm.*) which I > > checked-in temporarly. I think, once the standard is approved and > > there is an official release of the interfaces, we will be able to > > remove javax.wvcm.* from our CVS. > > > > I agree that the stuff under proposals/wvcm is not yet ready to be > > released. As a member of the JSR-147 EG I can tell that the spec just > > passed its 1st public review but is still highly subject to changes. > > Currently, the implementation at proposals/wvcm (org.apache.wvcm.*) is > > compliant with the version which went out for public review ... I'll > > keep it up-to-date with what's going on at JSR-147. > > > > Nevertheless, I would like to make some advertising for the wvcm > > implementation here :-). If somebody is looking for a WebDAV client > > lib ... the wvcm implementation is an alternative to the Slide-Client > > lib ... give it a try !! As the spec very much focuses on DeltaV and > > does not cover all of WebDAV, I have added some non-standard > > extensions for locking, DASL and ACL which I have proposed or will > > propose to the JSR-147 EG. So, the org.apache.wvcm.* implementation > > covers a lot of WebDAV right now. > > Uh, that's interesting! > > do you think that in the future we might be able to use wvcm instead of > the client library? do you see any drawbacks? > > would be totally cool if slide had two JSR-based APIs, one for client > (147) and one for server (170), using webdav in between, it would the > *ultimate* standard-complaincy. I don't understand how jsr-170 fits into slide at the moment... Can someone please explain? Is it not a replacement for the slide core api? So what is the way to go: 1. Putting jsr-170 in front of slide api, so that implementation of jsr-170 talks with slide api This would mean that there are different ways to access the repository data: a) server side java-app -> jsr-170 impl -> slide-api -> stores(=data) b) webdav-client -> webdav-servlet -> slide-api -> stores c) server side java-app -> slide-api -> stores Drawback: Many layers = low performance. E.g. events in jsr-170 impl must listen to slide events in order to fire jsr-170 events (to catch events that are fired if repository is accessed via webdav or direct slide-api access). 2. Dropping the slide-api and implementing a complete new core based on jsr-170 a) server side java-app -> jsr-170 impl -> stores(=data) b) webdav-client -> webdav-servlet -> jsr-170 impl -> stores This would mean a complete rebuild of slide core and the webdav layer. What exactly is the target of jsr-170? Is not webdav the standard to access a content repository? JSR-147 seems to be the standard to access a content repository via java api. So what is the use case for jsr-170 api? Is it only the webdav layer or is there any imaginable server side application that needs to access the repository via jsr-170? regards, Daniel > > It will probably be waaaay down the road, but having that goal now > would be a plus IMO... slide could become the reference implementation > of both all 147, 170 *and* WebDAV (since mod_dav is not catching up > with the new drafts and subversion is aiming at a totally different > thing: replacing CVS) > > -- > Stefano, really excited about this. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
