> -----Original Message----- > From: Slide Users Mailing List [mailto:[EMAIL PROTECTED] > Sent: Monday, September 13, 2004 3:58 PM > To: [EMAIL PROTECTED] > Subject: RE: Using the slide api directly vs. using the webdav client > Importance: Low > > > I don't know much about the slide API, but would it be fair > to say that the WebDAV client is a distributed HTTP > client/server design that can be made to scale more easily > and be more fault tolerant for large scale deployments?
It probably depends on the actual case. For example, our application is actually a webapp running in the same container where Slide runs. So a user can work either directly with Slide by means of some simple client - WebFolders, for instance, - or use our front-end which provides users with extensive capabilities not available in simple clients. So our back-end should use either core or WebDAV client. We decided against WebDAV client from considerations of performance mostly. And we have just a web-interface, not a full-fledged front-end, which definitely requires some WebDAV client to access Slide. > Since the slide DAV servers can be HTTP load-balanced and > configured in a clustered configuration and the WebDAV client > can make requests transparently to any slide server? Can't one use the same scalable/clustered config but make requests directly - I mean, without this WebDAV client proxy? Please correct me, if I'm wrong or if I have misunderstood you. Or do you suggest running two application servers - one for the slide only and another for the custom back-end which calls slide by means of the WebDAV client - so that both can be load-balanced/clustered/etc.? > Or is the slide API also a remote API to the slide server too? No, it's not. Yours sincerely, Andrey. > -----Original Message----- > From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] > Sent: Monday, September 13, 2004 2:48 PM > To: 'Slide Users Mailing List' > Subject: RE: Using the slide api directly vs. using the webdav client > > > Nick, > > first of all, as Kiran has already said, performance should be better. > Then, > getting rid of one extra layer that you might not need should > make your app > more robust. Webdav client has its fair share of bugs, afaik. Finally, > slide > core api is more handy. It's just my opinion, of course, and > I'm not well > familiar with the client. > > Yours sincerely, > Andrey. > > > -----Original Message----- > > From: Slide Users Mailing List > [mailto:[EMAIL PROTECTED] > > Sent: Monday, September 13, 2004 3:13 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Using the slide api directly vs. using the > webdav client > > Importance: Low > > > > Andrey > > > > That's very interesting to hear. I had been intending to do > > all my work with the slide api, as opposed to the webdav api. > > So, for creating structure ("folders", users, adding > > documents) I can use the server api, but for checking out and > > versioning documents, I will have to use the webdav api. > > > > Do you see any inherent advantage beyond this to using one > > api over the other ? (ie, webdav vs. server api) > > > > Nick > > > > -----Original Message----- > > From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] > > Sent: Monday, September 13, 2004 2:08 PM > > To: 'Slide Users Mailing List' > > Subject: RE: Using the slide api directly vs. using the > webdav client > > > > You are welcome. If you have more specific questions about > > slide "core" > > api, > > don't hesitate to ask. Just keep in mind that currently it is > > somewhat flawed - for instance, some important parts of > > versioning and binding mechanism are implemented in slide's > > "webdav" layer only. > > > > Yours sincerely, > > Andrey. > > > --------------------------------------------------------------------- > 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]
