> do you think that in the future we might be able to use wvcm > instead of > the client library?
Sure. I mean, the impl is in an advanced state. Almost all of what is specified in the public review version (end of 2003) is done. Still missing are mainly 2 things: 1. Support for deltav advanced features (merge, activities, baselines and versioned colls) ... mainly because these are missing in the Slide server impl too :) 2. Local resource proxies are missing. I think I need to explain local proxies a little bit. In WVCM you use resource proxies (interface "Resource" and sub-interfcs) to operate on a resource (read/write props/content, checkout/-in, bind/unbind, etc.). Resources have a "Location" which mainly wrappes the URL. Typically, a resource proxy is sort of a handle for a resource on the server and it's location typically is something like http://myhost:8080/slide/files/foo. Now, WVCM defines local proxies to represent local copies of resources to support e.g. working offline or client-side workspaces. A local proxy's location typically point somewhere to the local filesystem, e.g. file://fs4711/files/foo. WVCM defines some mechanics for synchronizing between the local and the server proxies. > do you see any drawbacks? No. WVCM has already been used in a couple of projects at my company. To be honest, some of my colleagues complained a little bit about WVCM as they think it takes getting used to. The reason maybe is that WVCM intentionally has been kept rather simplistic ... I my be biased, but think it is coherent. Regards, Peter > -----Original Message----- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: Saturday, February 07, 2004 02:31 > To: Slide Developers Mailing List > 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. > > 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]
