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

[Michal Skrivanek]

On Jun 24, 2013, at 10:08 , Itamar Heim <iheim at redhat.com> wrote:

> 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.

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