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.
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
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
pro: architectural flexibility, client language neutrality con: speed, network overhead
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
