[Sorry - want to send as a new subject for better discussion tracking] 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.
