>> Did I miss some implication of the libvirt connection? Can an alternate >> client solution be leveraged instead? > > Not sure what you mean about alternate client solution - alternate to > the above? concerning libvirt, it doesn't change anything. Libvirt deals > with the vm control, setup, migration, upgrade of qemu without affecting > the guest, but it doesn't provide the spice client, the, well, spice > client does that :)
Well, I don't know; I was wondering if in my ignorance I had missed a solution path that would be obvious to someone else. Looks like I didn't :-/. > > I think a html5 client (meaning Javascript / HTML5) would be the best > approach. Adding websocket support is the easy part, I think it should > be done directly in the server but a proxy also makes sense later. The > harder part is writing the client. But such a client would have a number > of deficiencies compared to a native client: > * less compression - probably not possible to implement QUIC / ZLIB or > any other compression that isn't provided by the DOM. (this is from > the noVNC experience). > * no usb remoting (also no smartcard, but that's less of an issue). Yes, and in general, I think an html5 client would have to have a somewhat reduced feature set. > > And the main problem: > * no one stepped up to write one. That's always the rub, isn't it :-/. I've been toying with the idea of trying to put together a proof of concept html5 client. That's likely to be folly, but I did want to be sure no one else was working on it. Cheers, Jeremy _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
