----- Original Message ----- > From: "Oved Ourfalli" <[email protected]> > To: "Geert Jansen" <[email protected]> > Cc: "engine-devel" <[email protected]>, "Eoghan Glynn" > <[email protected]> > Sent: Monday, April 16, 2012 10:44:31 AM > Subject: Re: [Engine-devel] REST session management > > > > ----- Original Message ----- > > From: "Geert Jansen" <[email protected]> > > To: "Oved Ourfalli" <[email protected]> > > Cc: "engine-devel" <[email protected]>, "Eoghan Glynn" > > <[email protected]> > > Sent: Monday, April 16, 2012 10:26:18 AM > > Subject: Re: [Engine-devel] REST session management > > > > Hi Oved, > > > > +1 for this feature. > > > > [[As a background to the others on the list, this feature is > > absolutely > > essential for certain types of ISV integration. Many ISVs need to > > mirror > > the RHEV inventory (i.e. all VMs, clusters, basically any object > > managed > > by RHEV) in realtime to their own database. The way they do this > > currently is by polling /api/events and look for changes. In order > > to > > be > > able to react to changes fast, they typically poll every 5 seconds. > > The > > query itself is very efficient, so it doesn't cause a whole lot of > > load > > on RHEV-M. But it floods the log with login/logout events. This > > persistent session feature is a solution for that.]] > > > Thank you for the background. I'll add it to the wiki page. > > > Actually my vote would go for your variation #2: > > > > The client passes the "Prefer" header field on every request, > > besides the last one. When the server gets a request with a > > JSESSIONID, and without the "Prefer" header, it logs out the > > session. > > > > It's mostly my gut feeling, but i would say it has these > > advantages: > > > > 1. It is more explicit, as on every request you confirm that you > > still > > want the authenticated session to be maintained. > > 2. It is also consistent with the default we have chosen of no > > persistent authentication. > > 3. It does not need a second header, so it is somewhat simpler. > > > > I Agree on that, although I'm not sure whether it is really needed to > release the session, rather then rely on timeout. > If we indeed need to provide a way to release the session then I > agree this is the best alternative. But if we don't then it will > make the API to the client more (but not very) complex in that > manner. I would go for both - release mechanism (for proper handling) and timeout mechanism for garbage collection. (refer to: http://blog.synopse.info/post/2011/05/24/How-to-implement-RESTful-authentication)
> The only doubt I have about that is that from reading on the new > "Prefer" header, I got the feeling that it is more relevant on > session negotiation, and less something you would pass on every > request in the session, but I'm not sure about that. > > > Regards, > > Geert > > > > On 04/15/2012 01:06 PM, Oved Ourfalli wrote: > > > Hey, > > > > > > The following wiki page describes a new feature - supporting > > > session management via the REST API: > > > http://www.ovirt.org/wiki/Features/RESTSessionManagement > > > > > > Please review and comment. > > > > > > Thank you, > > > Oved > > > > -- > > Geert Jansen > > Sr. Product Marketing Manager, Red Hat Enterprise Virtualization > > > > Red Hat S.r.L. O: +39 095 916287 > > Via G. Fara 26 C: +39 348 1980079 (when in US: > > 415-623-0542) > > Milan 20124, Italy E: [email protected] > > _______________________________________________ > > Engine-devel mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
