Re: [Engine-devel] SPICE Foreign Menu Using REST

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/20/2013 03:13 PM, Tomas Jelinek wrote:


----- Original Message -----
From: "Itamar Heim" <iheim@xxxxxxxxxx>
To: "Christophe Fergeau" <cfergeau@xxxxxxxxxx>
Cc: "Tomas Jelinek" <tjelinek@xxxxxxxxxx>, "engine-devel" <engine-devel@xxxxxxxxx>,
spice-devel@xxxxxxxxxxxxxxxxxxxxx, "Marc-André Lureau" <mlureau@xxxxxxxxxx>
Sent: Thursday, June 20, 2013 1:09:21 PM
Subject: Re: [Engine-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




_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]