----- Original Message ----- > From: "Michael Pasternak" <mpast...@redhat.com> > To: "Oved Ourfalli" <ov...@redhat.com> > Cc: engine-devel@ovirt.org, a...@ovirt.org > Sent: Monday, February 25, 2013 12:33:01 PM > Subject: Re: [Engine-devel] REST API calls from > > On 02/24/2013 03:01 PM, Oved Ourfalli wrote: > > > > ----- Original Message ----- > >> > From: "Doron Fediuck" <dfedi...@redhat.com> > >> > To: "Michael Pasternak" <mpast...@redhat.com> > >> > Cc: "Oved Ourfalli" <ov...@redhat.com>, engine-devel@ovirt.org, > >> > a...@ovirt.org > >> > Sent: Sunday, February 24, 2013 1:20:12 PM > >> > Subject: Re: [Engine-devel] REST API calls from > >> > > >> > > >> > > >> > ----- Original Message ----- > >>> > > From: "Michael Pasternak" <mpast...@redhat.com> > >>> > > To: "Oved Ourfalli" <ov...@redhat.com> > >>> > > Cc: engine-devel@ovirt.org, a...@ovirt.org > >>> > > Sent: Sunday, February 24, 2013 9:47:28 AM > >>> > > Subject: Re: [Engine-devel] REST API calls from > >>> > > > >>> > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > >>>> > > > > >>>> > > > > >>>> > > > ----- Original Message ----- > >>>>> > > >> From: "Doron Fediuck" <dfedi...@redhat.com> > >>>>> > > >> To: "Michael Pasternak" <mpast...@redhat.com> > >>>>> > > >> Cc: engine-devel@ovirt.org, a...@ovirt.org > >>>>> > > >> Sent: Thursday, February 21, 2013 6:54:59 PM > >>>>> > > >> Subject: Re: [Engine-devel] REST API calls from > >>>>> > > >> > >>>>> > > >> > >>>>> > > >> > >>>>> > > >> ----- Original Message ----- > >>>>>> > > >>> From: "Michael Pasternak" <mpast...@redhat.com> > >>>>>> > > >>> To: "Doron Fediuck" <dfedi...@redhat.com> > >>>>>> > > >>> Cc: engine-devel@ovirt.org, a...@ovirt.org > >>>>>> > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > >>>>>> > > >>> Subject: Re: [Engine-devel] REST API calls from > >>>>>> > > >>> > >>>>>> > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: > >>>>>>> > > >>>> > >>>>>>> > > >>>> > >>>>>>> > > >>>> ----- Original Message ----- > >>>>>>>> > > >>>>> From: "Michael Pasternak" <mpast...@redhat.com> > >>>>>>>> > > >>>>> To: "Libor Spevak" <lspe...@redhat.com> > >>>>>>>> > > >>>>> Cc: engine-devel@ovirt.org, a...@ovirt.org > >>>>>>>> > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM > >>>>>>>> > > >>>>> Subject: Re: [Engine-devel] REST API calls from > >>>>>>>> > > >>>>> the GUI > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> Hi Libor, > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> This issue came across in one of the conversations > >>>>>>>> > > >>>>> i had with > >>>>>>>> > > >>>>> UX > >>>>>>>> > > >>>>> folks, but since we didn't end > >>>>>>>> > > >>>>> up with any conclusion/road map (nor discussed it > >>>>>>>> > > >>>>> properly to > >>>>>>>> > > >>>>> hear > >>>>>>>> > > >>>>> other thoughts), this is a perfect > >>>>>>>> > > >>>>> place to start this discussion, > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> Intuitively REST is a way to go with GWT AJAX > >>>>>>>> > > >>>>> calls > >>>>>>>> > > >>>>> --------------------------------------------------- > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> pros > >>>>>>>> > > >>>>> ==== > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> - api data objects can be reused by generating > >>>>>>>> > > >>>>> java classes > >>>>>>>> > > >>>>> (using > >>>>>>>> > > >>>>> jaxb) from the rest schema [1] > >>>>>>>> > > >>>>> - no backend logic will be duplicated as api > >>>>>>>> > > >>>>> abstracts the > >>>>>>>> > > >>>>> backend > >>>>>>>> > > >>>>> exposing RESTful collection/resources to operate > >>>>>>>> > > >>>>> on > >>>>>>>> > > >>>>> - development against api is "easy" as api > >>>>>>>> > > >>>>> describes itself > >>>>>>>> > > >>>>> in > >>>>>>>> > > >>>>> RSDL > >>>>>>>> > > >>>>> [2] > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> cons > >>>>>>>> > > >>>>> ==== > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> - implementing transport layer (HTTP) under GWT > >>>>>>>> > > >>>>> - implementing own j2xml/json/yaml/... marshalling > >>>>>>>> > > >>>>> layer > >>>>>>>> > > >>>>> - implementing own error handling mechanism > >>>>>>>> > > >>>>> - implementing REST callback mechanism (in GWT) > >>>>>>>> > > >>>>> - constant maintenance of the data objects > >>>>>>>> > > >>>>> generated from the > >>>>>>>> > > >>>>> api > >>>>>>>> > > >>>>> - painful for Java developers > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> Java-SDK > >>>>>>>> > > >>>>> -------- > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> pros > >>>>>>>> > > >>>>> ==== > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> - abstracts transport layer (leaving developer in > >>>>>>>> > > >>>>> standard > >>>>>>>> > > >>>>> Java > >>>>>>>> > > >>>>> api) > >>>>>>>> > > >>>>> - typesafe code (no need to mess with XML bulks) > >>>>>>>> > > >>>>> - has own data objects to work with > >>>>>>>> > > >>>>> - abstracts authentication/authorization > >>>>>>>> > > >>>>> (kerberos/cookie/session/etc.) > >>>>>>>> > > >>>>> - since SDK is auto-generated, it can be easily > >>>>>>>> > > >>>>> extended with > >>>>>>>> > > >>>>> required > >>>>>>>> > > >>>>> features to support UI (such as callback > >>>>>>>> > > >>>>> infrastructure for > >>>>>>>> > > >>>>> instance) > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> cons > >>>>>>>> > > >>>>> ==== > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> - has to be converted in to Javascript (not sure > >>>>>>>> > > >>>>> what the > >>>>>>>> > > >>>>> impacts > >>>>>>>> > > >>>>> are > >>>>>>>> > > >>>>> in terms of AJAX calls/etc.) > >>>>>>>> > > >>>>> - probably much more cons that we're not aware of > >>>>>>>> > > >>>>> and will > >>>>>>>> > > >>>>> have > >>>>>>>> > > >>>>> to > >>>>>>>> > > >>>>> figure out with POC > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> thoughts? > >>>>>>>> > > >>>>> > >>>>>>>> > > >>>>> [1] http[s]://server[:port]/api?schema > >>>>>>>> > > >>>>> [2] http[s]://server[:port]/api?rsdl > >>>>>>>> > > >>>>> > >>>>>>> > > >>>> > >>>>>>> > > >>>> Although started as a UI request, there are other > >>>>>>> > > >>>> needs who > >>>>>>> > > >>>> wish > >>>>>>> > > >>>> to use API calls with a different transport. For > >>>>>>> > > >>>> example a > >>>>>>> > > >>>> backend > >>>>>>> > > >>>> hook which gets a REST entry point it can use to > >>>>>>> > > >>>> fetch for > >>>>>>> > > >>>> additional > >>>>>>> > > >>>> data, or perform actions. In this case I'd expect an > >>>>>>> > > >>>> internal > >>>>>>> > > >>>> connection > >>>>>>> > > >>>> rather than creating additional connections. > >>>>>>> > > >>>> How would you resolve it generically enough in this > >>>>>>> > > >>>> context? > >>>>>> > > >>> > >>>>>> > > >>> Doron, > >>>>>> > > >>> > >>>>>> > > >>> I believe your approach a bit different, UX folks > >>>>>> > > >>> seeking for a > >>>>>> > > >>> convenient > >>>>>> > > >>> way of communicating with ovirt public api, e.g > >>>>>> > > >>> closing > >>>>>> > > >>> api<->GUI > >>>>>> > > >>> gap, and > >>>>>> > > >>> theirs alternatives where native HTTP layer or > >>>>>> > > >>> Java-SDK based > >>>>>> > > >>> framework, > >>>>>> > > >>> while what you need is in-process channel to > >>>>>> > > >>> communicate with > >>>>>> > > >>> the > >>>>>> > > >>> engine itself, > >>>>>> > > >>> > >>>>>> > > >>> i understanding your will of using stable api for this > >>>>>> > > >>> (RESTapi), > >>>>>> > > >>> but > >>>>>> > > >>> not > >>>>>> > > >>> sure that doing this via JavaSDK is a good way to go > >>>>>> > > >>> simply > >>>>>> > > >>> because > >>>>>> > > >>> SDK is > >>>>>> > > >>> designed to operate in a client-space, while what you > >>>>>> > > >>> need is a > >>>>>> > > >>> server-space > >>>>>> > > >>> bridge for that. > >>>>>> > > >>> > >>>>> > > >> > >>>>> > > >> Michael, true but... > >>>>> > > >> Thinking about it differently both UI and hooks needs a > >>>>> > > >> client. > >>>>> > > >> The underlying protocols should be abstracted. This is > >>>>> > > >> something > >>>>> > > >> which will serve other functions as well. > >>>>> > > >> > >>>> > > > > >>>> > > > I'm not sure we would need a new abstraction here. > >>>> > > > Both UI plugins and engine plugins need some API to do > >>>> > > > basic > >>>> > > > operations, and have access to different properties in the > >>>> > > > engine. > >>> > > > >>> > > +1, that's exactly what i've suggested to begin with. > >>> > > > >> > > >> > The only issue is that UI plugins and engine plugins shave > >> > different > >> > expectations > >> > from performance point of view. If UI is willing to wait for a > >> > refresh that may > >> > take too long for engine plugins, which would prefer to get the > >> > information as > >> > soon as possible without going into various communication layers > >> > which are not > >> > always needed. So again- a simple solution which enables > >> > transports > >> > layers to > >> > be replaced may serve more than one functionality in a better > >> > way. > >> > > > Let's start with the simple solution. We don't know yet who will > > the plugins, how would they be used, and whether using the SDK > > will be a bottleneck of any kind. If the proposed solution is to > > support different transport layers while still using the SDK, then > > it is an extension we can always do in the future, if we find it > > of high benefit. > > (btw, regardless of that, the API/SDK is now faster than in the > > past, as we support REST sessions, which removes the need to > > re-authenticate upon each API request). > > > > true, but the real bottleneck is sending XML bulks over the wire + > bi-directional marshalling X 2 (engine<->api + api<->xml). > Here we're in agreement.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel