> -----Original Message----- > From: Kevin Moran [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 15, 2003 1:24 PM > To: Slide Users Mailing List > Subject: RE: First Cut of a Revised Slide Architecture > > > James, > Thank you for the clarification. That does in > fact help. While I think more about what you wrote, > I'd like to ask a couple of other questions: > > 1) To what extent would the changes you're proposing > affect the current APIs?
My guess is that an API change may be required, mostly due to the transport agnostic case. I would harbor a guess that the current API assumes a lot about the kernel being inside the same VM. So, that would lead to the next question: what the API would look like.. Not sure yet on that one. I'd like something that of course would offer serializable beans and look simliar to other Java APIs such that the learning curve is minimized. That would include the adoption of patterns for the lookup of the service using either a protocol convention (http, jmx, etc), separation of the API from the transport service providers, etc. If one of the 2 JSRs on CMS make sense, great! But, I haven't dug into them enough to know yet.. WRT JSR 147, here is the info I've obtained so far: <emails> Email #1: Hi James, We only made a couple of changes from the Community Review (a missing property name, and an additional "retryCount" parameter for the authentication routine), so the current WVCM interface is likely to be the final interface, unless problems show up during implementations. So the most helpful thing you can do at this point is forge full speed ahead with your implementation, and let us know if you encounter any problems! Also, if you can accumulate any test routines that you could contribute to the TCK, that would be very helpful as well. Cheers, Geoff Email #2: http://www.webdav.org/deltav/wvcm The JCP gives me very limited control over the visibility of information at the JCP site, so I currently am keeping a copy of everything at the webdav site. Cheers, Geoff Email #3: Currently, we have at least one group interested in doing a WebDAV/DeltaV-based implementation of WVCM, and I've told them we'd love to have that as part of the reference implementation, but we don't yet have a commitment from them for that yet. Cheers, Geoff </emails> Feel free to jump into the API more on this one and maybe even JSR 170. I'd love to get a task kicked off and complete soon as to what the API around the kernel should look like. As for the course grained API, that will probably just be a wrapper API that does more discrete units of work on behalf of the client to keep the CMS state WebDAV-compatible. My guess is that if we craft a small doc using the existing DocBook XML format (I'm assuming its docbook) from the current Slide build, we could produce some docs and offer then up for comment from the public by posting to JavaLobby, TheServerSide, Java Channel, et. al. > > 2) Would any of the changes you're proposing improve > the code with respect to caching? I haven't considered that to this point, but my first thought is to get it working, then optimize with caches. If the current caching mechanism is sound and would transfer to the new API smoothly, then maybe we just expose a configuration setting in the domain.xml to turn it on or off?! I hadn't noticed the problem since I plan on using a web interface for my current project and webdav clients only for things I don't offer via the web interface during the early interations. James --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
