> 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.?
Right. I'm referring to a configuration that we're planning to use with multiple slide servers that are clustered for failover and load-balancing with a single (or multiple) slide WebDAV client-based applications front-ending the servers and a HTTP load-balancer (or tomcat load-balancing) in between. In this case if a single slide server goes down, or the load is high, then requests can be farmed out to the rest of the slide cluster for maximum uptime and performance. The slide servers share the same content repository between them. With a slide api app that's coresident with the slide server, in the same web container and making calls directly to slide, then I didn't think it was possible for this client app to failover to another slide server (in another app server?) in the event of failure. That is, unless the slide api has been written to use remote calls to find other slide servers on the same machine or another machine? Or does J2EE take care of it somehow?? I really don't know enough about the possible scenarios for deploying the slide api and server so I'll ask some questions about your configuration :-) What happens if the app server hosting your slide api client and slide server goes down? Do you have a failover app server to go to in this event? Does each failover app server run its own instance of the slide api app and slide server? Do the slide servers share the same content repository? Warwick -----Original Message----- From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 3:36 PM To: 'Slide Users Mailing List' Subject: RE: Using the slide api directly vs. using the webdav client > -----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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
