On Jun 24, 2013, at 10:08 , Itamar Heim <iheim@xxxxxxxxxx> wrote: > On 06/24/2013 11:02 AM, Michal Skrivanek wrote: >> >> 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. >> > > 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. i don't think it would be needed. We don't really need much features on spice client side except for displaying and invoking a generic REST call. Items support is based on Engine side if the menu is supplied by Engine side. > >> >>> >>>> >>>>> 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