Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST

On 06/24/2013 11:02 AM, Michal Skrivanek wrote: > > On Jun 20, 2013, at 14:27 , Itamar Heim <iheim(a)redhat.com&gt; wrote: > >> On 06/20/2013 03:13 PM, Tomas Jelinek wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" <iheim(a)redhat.com&gt; >>>> To: "Christophe Fergeau" <cfergeau(a)redhat.com&gt; >>>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt;, >>>> spice-devel(a)lists.freedesktop.org, "Marc-André Lureau" <mlureau(a)redhat.com&gt; >>>> Sent: Thursday, June 20, 2013 1:09:21 PM >>>> Subject: Re: [Engine-devel] [Spice-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. > this forces you to maintain backward compatibility in the "Menu API", the client to handle ignoring new features/items in the menu they don't support yet, etc. while the *data* which is the important part is already in the stable, backward compatible, API.

> >> >>> >>>> iiuc, we are on the same page. >>>> >>>>> >>>>> Christophe >>>>> >>>> >>>> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >