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

[Itamar Heim]

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.

>
>> iiuc, we are on the same page.
>>
>>>
>>> Christophe
>>>
>>
>>