I don't think that jsr170 supports all the features that are required by WebDAV. The Slide core has some nice features that can't be found in the jackrabbit core up to now. So my personal favourite would be to build a java api that reflects the WebDAV protocols in a simpler and local/remote neutral way as it is described in the Slide 3.0 design approach in the wiki ;-)
Daniel > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im > Auftrag von John Gilbert > Gesendet: Mittwoch, 1. Dezember 2004 05:14 > An: Slide Users Mailing List; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Betreff: RE: Slide and JSR170 > > > Just some food for thought to help protect your software from this > duplication... > > If I were to start from scratch (not that I would) I would create an > architecture that uses both in a multi-layered fashion. > > On the java client side (e.g. Swing) I would: > - wrap a webdav api (e.g. slide) with the jsr170 api > - this allows the client to access any webdav server > - allows swapping jsr170 implementations > - allows for swapping client-side CM tools that are used locally > and > don't need http. I think this is along the lines of jsr-147. > > On the server side I would: > - expose the external facing/remote interface using webdav > - this allows existing clients to access it > - it also allows streaming large files over http which is more > scalable then the non-streaming rmi alternative > - internally I would use the jsr170 api so I don't have to define my own > - the server could also act as a webdav client and use the wrapper > mentioned above > > I use this logical architecture as a reference model when I need to > decide what to use where and to help protect/decouple me from those > choices. > > - John > > > > -----Original Message----- > From: Jeff Broberg [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 30, 2004 7:57 PM > To: [EMAIL PROTECTED]; 'Slide Users Mailing List' > Subject: RE: Slide and JSR170 > > Thanks for the response. I quess my question is, "What is the overall > architecture for CMS as far as Apache goes ?" There seems to be quite a > bit > of duplication, and I am not sure why slide wouldn't use jackrabbit, or > 170. > They seem like the logical stack. I agree with your assessment re: > webdav. > It is more global in nature. > > Just curious, why do you recommend against using the server Slide API. > Is > it because it is only relevant to slide ? If so, I agree, because it > causes > technology lockin. So, if that is the case, what is the benefit of the > server api at all ? > > Jeff > > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 30, 2004 6:08 PM > To: Slide Users Mailing List; [EMAIL PROTECTED] > Subject: Re: Slide and JSR170 > > Slide does not support JRS170. Jackrabbit isn't used either. It's the > other > way round as well, Jackrabbit does not use Slide either. > > I guess there are quite a number of parameters included in the decision > which way to go, so I really can not make any recommendation. > > Good thing about WebDAV is that there already are a number of > applications > supporting it. Drawback would be that WebDAV by nature is a client/sever > protocol, so you would always have the communication overhead. On the > other > hand while JSR170 covers only certain aspects of a content store, WebDAV > is > pretty much complete. Additionally, programming against JSR170 would > restrict you to Java solutions. > > I *personally* would not at all recommend programming against the sever > Slide API... > > Oliver > > On Tue, 30 Nov 2004 17:52:17 -0500, Jeff Broberg <[EMAIL PROTECTED]> > wrote: > > Ok, simple question. Is the Slide API based on JSR170 ? If so, is > > JackRabbit used inside Slide ? We are considering if we should write > > our java clients to use WebDAV client protocols or use the Slide API, > > or if possible the 170 api. > > > > Any guidance would be appreciated. > > > > Jeff > > > > > > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
