Hi, >> What is the use case? Any reason why the spice client can not (or >> should not) speak to ovirt directly? > > Ah, in fact, it's the main reason why I worked on this. Currently, the > Spice client has to communicate with ovirt via the browser, which is a pain > to deal with: it's a completely different route, it needs a running > browser, a compatible extension (xpi vs activex vs the rest not supported), > leading to duplicated work, license problems, regular breakage between > browser versions, hard to test, difficult to upgrade... Understood. > Instead, we are > investigating the use of a configuration file provided by ovirt portal for > setting up the client, and the dynamic interaction could take place either > via the propose Spice port, or directly via ovirt. > > Some of the dynamic ovirt functionality are interesting for direct clients, > like the "spice controller menu" (a customizable client UI menu, > virt-viewer and Boxes could benefit it). It may not be the best solution to > route the "ovirt/spice controller" through qemu host, but at least I wanted > to try that option. It could be that in the end, it is prefered that the > client just talk directly to ovirt, whatever fits best. I'd go for a direct connection. Going the indirect route via qemu probably isn't as bad as going indirectly via browser, but still. Unless there is a very good reason to use qemu as middle man I simply wouldn't do that. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel