> -----Original Message----- > From: Stephan Michels [mailto:[EMAIL PROTECTED] > Sent: dinsdag 13 april 2004 19:50 > To: Cocoon Developers > Subject: [RT] Future of the Slide Source > > > Hi, > > I currently think about the Slide/WebDAV access layer, since I > need it for my next project. The access to the Slide repository was my > first approach in the past, and perhaps not the best. The Slide API is > some parts very beautiful, but not intended to be used > outside of Slide.
Slide provides at least two ways to embed and access its API in client applications. It may be the less portable way to use Slide but I wouldn't go so far as to say that Slide is not intended to used in other ways as well. > Nevertheless running Slide and Cocoon side by side is pretty cool. > Yes :-) > So, I think the WebDAV access is the way to go. The Source IF is > already an abstraction layer, so I don't need another like > JSR170(in my > POV). > That is the way I use Slide as well. > The Repository IFs seems be more helper classes than components. And I > think we should using the Source objects instead to reflect > all aspects > like locking, property handling etc. > Oh no no no please! Stacking up interface upon interface is NOT a nice design at all IMHO. I REALLY don't like this. In fact I tend to think that a Source should be just the Source interface itself. All additional funtionality should come in the form of helper classes, again IMHO. > My proposal is to drop the Slide Source, but leave the Slide server as > option, and using the Slide block in the same sense as the > hsqldb block. I don't understand your rationale. The Slide Source is there, it may have it's uses in some scenarios. Why throw away something that is working perfectly well? > So that we can use Slide as WebDAV server for our WebDAV examples. I have been thinking about making the WebDAV samples work with Slide as WebDAV server as well. But throwing out SlideSource is no prerequisite for that. -- Unico
