Daniel thanks really for all your feedback.
Just one last question:
If I decide to use the Slide APIs directly and turn off Slide's Security
Checks using SlideTokenWrapper
SlideToken token = new SlideTokenImpl(credentials);
token.setEnforceLockTokens(true);
SlideToken tokenWrapper = new SlideTokenWrapper(token,true);
tokenWrapper.setForceSecurity(false);
And provide my own LockStore, since I will be maintaining user list in my
own Schema. Will this configuration significantly reduce the performance
bottleneck? Basically, is security check the main performance impairer?
Regards and Thanks,
Ritu
> -----Original Message-----
> From: Daniel Florey [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 30, 2004 5:15 PM
> To: Slide Users Mailing List
> Subject: Re: Which API should I use for a web app?
>
>
> Ritu Kedia wrote:
>
> >Hello Daniel,
> >
> >Thanks a lot for your reply. Please find my comments inline.
> >
> >
> >
> >>-----Original Message-----
> >>From: Daniel Florey [mailto:[EMAIL PROTECTED]
> >>Sent: Tuesday, March 30, 2004 3:08 PM
> >>To: Slide Users Mailing List
> >>Subject: Re: Which API should I use for a web app?
> >>
> >>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.)
> >>
> >>
> >>
> >
> >If the performance impact occurs inside the Slide Kernel,
> then how would it
> >be different when accessed via a Web-Client as opposed to a
> Desktop-Client?
> >The only difference is: in case of a Web-Client I would use
> some JSP/XSP and
> >in case of a Desktop-Client I would use some Web-Service.
> With both the
> >JSP/XSP and Web-Services internally using the Slide Client
> LIB to access
> >Slide's WebDAV Service.
> >
> >In your example above, when you say "retrieving data from
> Slide", do you
> >imply retrieving actual Content or retrieving any
> information: MetaData or
> >Content?
> >E.G. 1. if the client(Web/Desktop) wants to view all the
> sub-folders inside
> >a folder, a Slide WebDAV <ls> command would be issued and
> the results would
> >be wrapped in respective format and returned to the client.
> >E.G. 2. if the client(Web/Desktop) wants to download all the
> files in a
> >folder, a recursive Slide WebDAV <Get> command would be
> issued and the
> >results would be wrapped in respective format and returned
> to the client.
> >Will there be performance impact in both cases or only case 2 (large
> >information download)?
> >
> >Sorry for going into so much details... But I really did not
> understand the
> >difference between a Web-Client and a Desktop-Client. The
> security and lock
> >checks would be required in both cases. And most likely both
> cases would be
> >communicating with server over http.
> >
> >
> >
> >
> >>>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.
> >>
> >>
> >
> >When using the Client LIB, wouldn't there be a big
> performance difference
> >due to the additional HTTP communication layer introduced(I
> am referring to
> >using Client LIB from inside a JSP or Web-Service on the
> Server side)?
> >(Having the Slide APIs run in the same VM is acceptable).
> >However I think not having a clean separation between the
> WebDAV and the
> >Slide API layer would mandate the use of the Client or WVCM
> libraries.
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >.
> >
> >
> >
> Hi,
> there is no performance difference in using slide from webapp or
> desktop-client view. But normally it is more acceptable if
> you e.g. want
> to save a word document to slide or load it and wait a few
> seconds for
> it. Or if you open a folder in webfolder view it is acceptable if it
> takes another several seconds. But if you want to build a webapp the
> user in not used to wait several seconds for a page. And also
> there are
> much more parrallel users using a webapp than document editors.
> So if you want to build a dynamic webapp based on slide
> stored content,
> it will be damned slow if you don't cache the rendered pages until
> content is changed.
> I've integrated the event based stuff to enable some webapp like this.
> But it depends on the needs of your application.
> The protocol layer will for sure add some overhead, but this
> is not the
> big point. As the slide API will probably change in future
> releases it
> would be my strong advice to use the webdav api instead.
>
> Regards,
> Daniel
>
>
>
>
> ---------------------------------------------------------------------
> 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]
