On Jun 24, 2013, at 10:08 , Itamar Heim <iheim@redhat.com> wrote:
On 06/24/2013 11:02 AM, Michal Skrivanek wrote:
On Jun 20, 2013, at 14:27 , Itamar Heim <iheim@redhat.com> wrote:
On 06/20/2013 03:13 PM, Tomas Jelinek wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Christophe Fergeau" <cfergeau@redhat.com> Cc: "Tomas Jelinek" <tjelinek@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, spice-devel@lists.freedesktop.org, "Marc-André Lureau" <mlureau@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel