[Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
Marc-André Lureau
mlureau at redhat.com
Wed Jun 19 14:31:58 UTC 2013
----- Mensaje original -----
> 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
>
How does the client know what vmID it should access? The client shouldn't need to know how to form the base menu URL itself.
Regarding the XML, most of the elements would be nicer as properties imho.
- "id"
What is this used for?
- "text"
Why not just call it "label"? "text" is quite generic name, could be a hint etc.. Btw, is the menu localizable and should the client add the LC_LANG or something in the request?
- "marked"
I suggest to follow Gtk/Qt naming "checked", since we expect a check mark next to the label.
- "item_code"
This is quite badly named. Afaik, none of the Spice client implemented accelerators via the menu (it isn't specified in http://spice-space.org/page/Whiteboard/ControllerProtocol). I think in the past there was no default menu provided by the client but the one created by the portal. So the client was configured with CONTROLLER_HOTKEYS and just displayed whatever the menu text was. There was no additional accelerators created. So, this should be considered as a new feature.
I would also like to see the accelerator format specified somewhere (shift, ctrl, alt, fN, char seperated by + afaik)
It could be useful and easy to add a "sensitive" property too already.
I would also like to see the "Comet" approach being discussed in alternatives, instead of the polling and the second refresh request, which I can imagine racy if two items are clicked quickly. Can we expect refresh reply in order (to allow "pipelining" of requests)?
thanks
More information about the Engine-devel
mailing list