James, Great work. Here is my 2 cents:
> 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?!) One of the factors that can broaden Slide's acceptance is having more data stores and making existing ones more flexible and powerful. I think data storage should attract more attention by raising its visibility if it is not a separate level in its own right. > 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. I haven't checked out the JSR(s) yet. I wonder where security should fit into the layer architecture. > 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. I already initiated development of a generic WebDAV Tag Library (http://www.servlets.com/archive/servlet/ReadMsg?msgId=326288&listName=taglibs-d ev). I am still waiting for Jakarta-Taglibs approval for this project. I'd love to fold this project into the revived Slide. -- Willie Vu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
