James, I think your approach significantly improves the architecture and usefulness of the framework. I really like the webdav aspect of the product, but removing the dependency of the Slide core on webdav is a logical step. Such a change would enable Slide to act as a universal content server for all of an organization's applications.
I was just going over my design patterns and it seems like you're describing a Bridge - http://home.earthlink.net/~huston2/dp/bridge.html - although I'd certainly listen to arguments for other patterns...the structural ones overlap alot and are always subject to interpretation. I'll throw my name in as a potential contributor towards this effort; its certainly a worthy cause. I'm going on vacation with me and not taking a computer. But, I'll bring a pad and paper (if it's good enough for Cray it's good enough for me) and see what I can come up with. I'd be interested to know what Abstractions people are interested in first. I think EJB and Webdav are obvious choices. Are there folks interested in other interfaces in the very near term? Larry James Higginbotham wrote: > Juergen, > > Thanks so much for answering all of these emails.. I have become quite informed > about the Apache projects in general and slide specifically AFA status and process. > Your time is much appreciated to help us understand how the process works. > > As for the CM API, I have to move forward on my project currently to get locking and > editing via Struts going now, so I'll plan on moving the xxxMethod executeRequest > logic over as needed. I'll see if I can draw up a prelim arch overview of how I > would envision Slide with a CM only kernel, and gateways such as WebDAV, JMX, EJB, > etc. Whether I build this API off of the JSR APIs or not, I haven't determined yet. > > My assumption is that your company only needs the webdav capabilities for Tamino, is > that right? Or, is this something you'd be interested in supporting? > > How many others on this list would agree that a new CMS API broken away from the > webdav spec would be useful? Or, is it just me? > > Thanks, > James > > > -----Original Message----- > > From: Pill, Juergen [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 14, 2003 6:54 AM > > To: 'Slide Users Mailing List' > > Subject: RE: Slide status (was: newbie question about slide future) > > > > > > Hello James, > > > > My (personal) concentration of effort is more about WebDAV > > (and the associated standards) than the current Slide CM API. > > I think Remy (and the JSR 170 team) is going to put some > > effort in this area. Your generic accessor idea looks pretty > > good and ambitious; it would be very nice, if you find > > yourself in the position doing this in Slide (IMO). > > > > Best regards > > > > Juergen > > > > > > > > -----Original Message----- > > From: James Higginbotham [mailto:[EMAIL PROTECTED] > > Sent: Donnerstag, 13. März 2003 16:52 > > To: Slide Users Mailing List > > Subject: RE: Slide status (was: newbie question about slide future) > > > > Juergen, > > > > > I regret, if you are unhappy with the current Slide > > > situation. Slide consists of many pieces (e.g. WebDAV client > > > API, server, cm API, GUI and command line clients, etc). Some > > > of those are actively worked on; some of those are currently > > > under lower development. > > > > Thanks for the information. I do respect the amount of work > > that has been put into Slide thus far - lots of > > "reading the spec and implementing" as well as creative > > extras. What I'm proposing is some enhancements to make it > > more viable beyond the direct webdav/deltav support. If my > > proposals stand outside the realm of where Slide wants to go, > > feel free to say so and I'll make a separate project to > > handle my requirements. Again, I want to help make Slide even > > better, as others do as well. Our concern is that its not > > supported well (I still have an outstanding question > > regarding locks from 3/6). If out of this thread we can > > "rally the troops" so to speak and get more doco, mailing > > list support by those that are digging in deeper, and some > > nice refactorings in the future, then my goal has been achieved. > > > > With that, I would be willing to assist in any design around > > a central kernel API that can be communicated via any number > > of gateways, and a revised set of struts tags and examples > > that would take advantage of this new API. I am on a project > > right now that needs this, so I am currently pulling code > > from the xxxMethod classes into my own API for now. > > Obviously, my project will have to come first but any spare > > time I have is yours - I would love to see this project > > really take off even more than it has already. > > > > Best Regards, > > James > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
