Re: [Engine-devel] REST session management

From: "Oved Ourfalli" <ovedo(a)redhat.com&gt; To: "Geert Jansen" <gjansen(a)redhat.com&gt; Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, "Eoghan Glynn" <eglynn(a)redhat.com&gt; Sent: Monday, April 16, 2012 10:44:31 AM Subject: Re: [Engine-devel] REST session management ----- Original Message ----- > From: "Geert Jansen" <gjansen(a)redhat.com&gt; > To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; > Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, "Eoghan Glynn" > <eglynn(a)redhat.com&gt; > 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.

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: gjansen(a)redhat.com > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel