[Spice-devel] Alternate platform exploration

[Jeremy White]

>> 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