Great, so it sounds like others may be interested in the advantages of this. What I'm thinking is a proxy pattern coupled with whatever else makes sense.. Here are some initial thoughts and outstanding questions:
1) I would like to have a JMX interface so I could deploy the kernel as an mbean inside JBoss. 2) Another protocol that would be nice would be direct invocation model, where if I know that I have a local kernel instance, I can talk direct to it and skip serialization/marshalling overhead 3) My thought is that there will be the following levels (imagine concentric circles, starting from the center): Level 1: Internal Kernel APIs - what we have now via the SlideToken + NamespaceAccessToken concepts for fine-grained access. Additional APIs will need to be identified at this level that haven't been done (for some reason, versioning comes to mind based on a past thread?!) Level 2: CM APIs - what we've really been talking about in the past week. Course grained APIs for performing locking and other tasks that are commonly handled by the WebDAV xxxMethod request processors. This would allow clients to perform webdav-like tasks against the kernel in a transactional context while having a more java-friendly api. Candidates could be the JSR(s) currently in development, or just using the webdav API object model here and moving the transport need for HttpClient vs. some other transport to level 3. Level 3: Gateway - this would offer a transport layer that would translate a transport into CM APIs at level 2. Examples include WebDAV over HTTP, JMX, SOAP, etc. Essentially, it would provide a proxy around the level 2 API and underneath the covers manage the transport calls as a client and offer whatever adapters (servlets, etc.) for the server side. One thing that falls here is the webdav client lib. Level 4: Taglibs - this would offer taglibs for Struts, JSTL, etc. that would utilize the gateway client - meaning, it could be direct invocation, JMX calls, or even WebDAV utilizing client proxies from level 3. Thoughts? Just wanted to get something out before Larry takes off for vacation. James > -----Original Message----- > From: Larry Adams [mailto:[EMAIL PROTECTED] > Sent: Friday, March 14, 2003 11:32 AM > To: Slide Users Mailing List > Subject: Re: Slide status (was: newbie question about slide future) > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
