On Jun 20, 2013, at 14:27 , Itamar Heim <iheim@xxxxxxxxxx> wrote: > On 06/20/2013 03:13 PM, Tomas Jelinek wrote: >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" <iheim@xxxxxxxxxx> >>> To: "Christophe Fergeau" <cfergeau@xxxxxxxxxx> >>> Cc: "Tomas Jelinek" <tjelinek@xxxxxxxxxx>, "engine-devel" <engine-devel@xxxxxxxxx>, >>> spice-devel@xxxxxxxxxxxxxxxxxxxxx, "Marc-André Lureau" <mlureau@xxxxxxxxxx> >>> Sent: Thursday, June 20, 2013 1:09:21 PM >>> Subject: Re: [Engine-devel] SPICE Foreign Menu Using REST >>> >>> On 06/20/2013 02:07 PM, Christophe Fergeau wrote: >>>> Hey Itamar, >>>> >>>> On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote: >>>>> On 06/19/2013 04:33 PM, Tomas Jelinek wrote: >>>>>> Hi all, >>>>>> >>>>>> for the non plugin invocation of the console >>>>>> (http://www.ovirt.org/Features/Non_plugin_console_invocation) the >>>>>> dynamicMenu property is not usable to enrich the SPICE client menu. >>>>>> >>>>>> This feature is about requesting this menu using oVirt's REST API and >>>>>> than calling it back once some item from this menu has been selected. >>>>>> >>>>>> The oVirt's feature page with specific details: >>>>>> http://www.ovirt.org/Features/Foreign_Menu_Using_REST >>>>>> >>>>>> Any comments are more than welcomed. >>>>> >>>>> Why are we putting the logic of the menu into the REST API? >>>>> can't the menu be builded by client based on getting the list of >>>>> ISO's and current CD? >>>> >>>> The client needs a way to get the list of available ISOs in order to build >>>> the menu, as well as a way to let the engine know when the user clicked on >>>> an ISO in the menu. One way of doing that is to have the menu stuff exposed >>>> in the REST API. Another way would be to expose the list of ISOs in the >>>> REST API (I'd have a slight preference for that I think). >>> >>> that's my preference as well, and the REST API should already do that today: >>> - get list of ISOs of available in a DC (the one the VM is in) >>> - ability to change the CD of the VM >> Well, and what about the stop/suspend VM for example, what we have in the menu today? > > supported as well. > >> Also this should be something that the client decide to have or not have? > > I think the client should decide on the features relevant to the client. > >> >>> >>>> Or do you have anything in mind for the client to get the list of ISOs >>>> available to the engine? >>> >>> my preference is to provide the data, not the semantics of the menu. >> We should clarify something here. There are two possibilities who should be responsible for deciding >> what should the foreign menu contain and also what to do if it the item is selected: >> 1: the client - e.g. we will not provide any support for the menu in REST because the client reads what needs >> and knows how to call the oVirt back >> >> 2: the server side - e.g. we will provide in REST side the menu structure with the description what to do if something is >> selected >> >> Both have some advantages and disadvantages but we need to clarify which way to go. So, who is the one responsible to decide >> what is in the foreign menu (now or in the future) and how to react if something is selected? Client or engine? > > my preference is the client will decide this, as there are various clients to the REST API, and each should decide which features are important for them. I would agree as long as it is not hardcoded and can be change in some config file easily. We shouldn't wait for next RHEL release to do a little modification if possible. I think "owning" the menu in some form on RHEV-M side has an advantage of delivery synchronization. > >> >>> iiuc, we are on the same page. >>> >>>> >>>> Christophe >>>> >>> >>> > > _______________________________________________ > Engine-devel mailing list > Engine-devel@xxxxxxxxx > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel