----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 5:25 PM Subject: Re: proposals/wvcm [was: RE: Licence for slide 2.0b]
> DISCLAIMER: this is my *very personal* opinion on the matter. There is > no official statement, either from apache or nobody else, and the > governance of the slide project and its decisions are entirely > community driven and will remain that way. > > DISCLAIMER2: as part of the JSR 170 expert group, I'm obviously biased > but I also tend to be very open minded. JSR 170 should be in public > review very soon and this also means that we can still adjust things in > teh API to meet the needs that would emerge from this community (like > we do for others as well). > > On 7 Feb 2004, at 06:09, Daniel Florey wrote: > > > > > ----- 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? > > Yes. > > > 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. > > My choice would be > > 3. Moving the slide-api on top of JCR for compatibility and migrate > webdav slowly on top of JCR. Hi Sefano, first of all I want to say that I hope my mail didn't sound like an offense. As a non native speaker it is sometimes hard to find the right wording. I'm really only interested in getting things sorted out. In general I'm a friend of refactoring if it is for a good intention. So if JSR 170 is really as mature as I hope it'll be, I will help to adapt parts of the core. If you say you want to put slide on top of jsr do you think of some kind of jsr170-store? Is it the intention of jsr170 to get one api to access several legacy repositories (like notes, cvs etc) if an implementation is done? If so I see the benefit for such an api. We could enable access to all of this repositories with just building one jsr170-store. But maybe I got it wrong again... Is jsr170 more a set of interfaces or does it implement some logic as well (e.g. mounting of different stores, configuration) > > > What exactly is the target of jsr-170? Is not webdav the standard to > > access > > a content repository? > > webdav is a protocol, JCR is an API. the parallel that comes to mind > would be HTTP and the Servlet API. > > > JSR-147 seems to be the standard to access a content > > repository via java api. > > Yes, client side. > > > So what is the use case for jsr-170 api? > > server side. > > > Is it only > > the webdav layer or is there any imaginable server side application > > that > > needs to access the repository via jsr-170? > > there are multiple scenarios. > > 1) embedded > > application -(JCR)-> repository I'm just curious if you have server side application in mind that needs access to a content repository but has no need to be clusterable. > > pro: speed > con: architectural flexibility > > 2) remote (via RMI) > > application -(JCR)-> -(RMI)-> repository > > pro: improved architectural flexibility (many application can access > the same repository) > con: speed, only java application can access it > > 3) remote (via webdav) > > application -(JCR)-> Webdav client -(WebDAV)-> Webdav server -(JCR)-> > repository Did you mean application -(JCR147)-> Webdav client -(WebDAV)-> Webdav server -(JCR170)->repository ? This is my favorit approach as it allows easy clustering for the application. regards, Daniel > > pro: architectural flexibility, client language neutrality > con: speed, network overhead > > -- > Stefano. > > > --------------------------------------------------------------------- > 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]
