Hi Daniel, This thread was of great interest to me, because very recently I experimented using Slide APIs directly from my Application. After reading this mail thread, I am considering using Slide's Client APIs instead of directly the server side APIs, though this would require me to code separately for distributed transaction management (My App specific DB operations + Slide operations --> in one atomic operation).
Before making the final decision, I wanted to confirm whether I understood this correctly: >BTW: Slide is (at the moment) far to slow to serve any webapp in real time. >I'm currently working on a process engine that is doing all the caching >and background-building of webpages so that a webapp can be build on top >of slide. It will take some weeks until it is at a usable stage, but >this might be a choice for webapps in the future. First of all: Why would Slide be used for building webpages? As I see it, Slide is Abstract Content Repository, which in turn could map to multiple physical Data Stores. In that sense, Slide is parallel to any other Data Store when viewed from an Application's perspective. And so the only difference is in the communication layer that an Application uses to communicate with any other Data Store and that with Slide. When you mention "background-building of webpages"... are you referring to the fact that Slide communicates over the WebDAV(HTTP extension) protocol and by that fact it would be required to return a webpage in response to any request? If yes, would that mean that the performance impact is due to the communication layer between a WebApp and Slide? In other words, the performance impact can be attributed to using Slide's Client APIs inside our WebApp. And that could be avoided if we access Slide APIs directly from inside our WebApp. Is this interpretation correct? I have diagrammatically represented the above scenario(Slide being accessed from a WebApplication). In this scenario do you see Slide being usable (basically will there be any performance issue)? My apologies if I misunderstood you. Regards, Ritu -----Original Message----- From: Daniel Florey [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 9:20 PM To: Slide Users Mailing List Subject: Re: Which API should I use for a web app? Hi Ryan, at the moment it is not recommended to use the slide api directly as you don't have access to many features that are hacked into the webdav layer. I don't know if versioning is working by using the slide api, there is some revision support but it is somehow mixed up with the webdav layer, so my advice would be not to use it. If you use slide api you are tied to the same vm so your webapp is not very scalable. The client library is a good way to access slide as the webdav-layer will not change soo much in future. WVCM is an abstraction layer on top of webdav, so it is little slower than webdav clientlib but it would be nice, if you would give it a try so that the jsr can get some feedback. Regards, Daniel BTW: Slide is (at the moment) far to slow to serve any webapp in real time. I'm currently working on a process engine that is doing all the caching and background-building of webpages so that a webapp can be build on top of slide. It will take some weeks until it is at a usable stage, but this might be a choice for webapps in the future. ryan wrote: >I'm looking at the slide client library, the slide API, and the WVCM >API, and I can't figure out which one I should use for a web >application. Can someone explain what the difference in these API's is? > >Does the Slide API support versioning? Would the Slide API be much >faster than the other two because of the network traffic? Which API >will support external transactions in the future? > >Thanks, > >Ryan Rhodes > > > --------------------------------------------------------------------- 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]
