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

[Michal Skrivanek]

On Jun 20, 2013, at 14:27 , Itamar Heim <iheim at redhat.com> wrote:

> On 06/20/2013 03:13 PM, Tomas Jelinek wrote:
>> 
>> 
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Christophe Fergeau" <cfergeau at redhat.com>
>>> Cc: "Tomas Jelinek" <tjelinek at redhat.com>, "engine-devel" <engine-devel at ovirt.org>,
>>> spice-devel at lists.freedesktop.org, "Marc-André Lureau" <mlureau at redhat.com>
>>> 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.


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