Ritu Kedia wrote:

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.


Yes, Slide is an abstract content repository but it depends on the kind of application you want to build on top of it, if it is really usable.
What I was talking about was a portal like webapplication using some of the content displayed to the user by using slide. If you are thinking of a totally different app, the performance problems might not occur.
Let's say you are thinking of a webapp that has several JSP-pages that work without retrieving data from slide while generating output and you have a download area where users can download documents it might be ok. But if you think of web pages that contain content that is stored in slide and will be retrieved while generating the page it will be really slow. The API you use will not make a very big difference as the performance problems occur inside the slide kernel (permission checking etc.)


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?


No, the api makes no big difference. You should use the webdav lib or wvcm to access slide, otherwise your app is bound to the same vm.
Regards,
Daniel


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]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to