3:13 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Christophe Fergeau" <cfergeau(a)redhat.com>
Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>,
spice-devel(a)lists.freedesktop.org, "Marc-André Lureau"
<mlureau(a)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?
Also this should be something that the client decide to have or not have?
> 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?
iiuc, we are on the same page.
>
> Christophe
>