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

[Itamar Heim]

On 06/24/2013 11:02 AM, Michal Skrivanek wrote:
>
> 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.
>

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 at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>