[Spice-devel] Alternate platform exploration

[Alon Levy]

On Wed, Mar 28, 2012 at 12:05:33PM -0500, Jeremy White wrote:
> I, like many before me, am interested in seeing a spice client on other
> platforms.  Things like Mac OS X, iOS, Android, HTML5, and so on.
> 
> I've spent a bit of time researching what has gone before, and thought
> I'd try to summarize what I've found.  Mostly that will show my
> ignorance and hopefully smarter people than I will rush to correct me
> and I'll learn something <grin>.
> 
> I gather that the primary focus of Spice development is around the spice
> gtk client.  That currently provides clients for *nix and Windows
> systems.  Spice-xpi lets you launch the client from a web browser so you
> get some modicum of browser integration.  libvirt integration lets you
> launch the client from vm managers, and related systems.
> 
> Spice-gtk and spice-common is where all the action is.  The interesting
> spice implementations are all in c code.
> 
> A proof of concept Mac implementation with Gtk has already been done. In
> theory, that's a straight forward, if potentially unsatisfying, solution
> for the Mac.  iOS and Android pose a much more substantial challenge,
> however.
> 
> I didn't see any evidence of active work on alternate platforms - if I
> missed that, please both accept my apologies and fill me in.
> 
> So, as I look around for ways forward, I've considered the following
> options:
> 
>   1.  Native versions for all
> 
>       This is probably the most satisfying option, but requires fairly
>       meaty work for Mac, iOS, and Android.  It also doesn't satisfy
>       the zero-installation I-want-it-in-my-browser people.  It also
>       imposes a long term maintenance challenge.
> 
> 
>   2.  HTML5 to rule them all
> 
>       This, afaict, requires a complete SPICE client written in
>       Javascript.  This is no small task, and creates a fairly serious
>       maintenance challenge.  The client is still evolving
>       fairly rapidly, and synchronizing two code bases will be tricky.
> 
>       It's also not clear if HTML5 can deliver the kind of performance
>       we all crave.
> 
>       But, if a functional client could be implemented, it
>       would effectively solve all the alternate platform issues, right?
> 
> 
>   3.  Chrome / Pepper / Native Client
> 
>       This approach would reuse the spice-common code, presumably,
>       and is a bit of hybrid.  It would be part Javascript, part
>       C code.  It would have similar, if more modest, maintenance
>       issues.  It would also only support Chrome (afaik, no
>       other browser has adopted the Native Client vision).
> 
>       I saw one person on the mailing list propose this, but I saw no
>       actual action on it.
> 
> 
>   4.  Use gtk/Broadway
> 
>       On the face of it, this would appear to be a compelling option.
>       Just rebuild the client to use the broadway backend, do some
>       server side footwork, and you have a solution similar to the
>       HTML5 vision.  But you have one code base.
> 
>       But then I realized that having broadway working on a remote
>       server just recreates the problem that spice is meant to solve,
>       once again serving to remind me of my own stupidity :-/.
> 
>       I can't find any reference to this being considered in the
>       mailing list archives, and a broader search finds me lots
>       of spicy restaurants on Broadway Ave :-).
> 
>       I can't help but feel that there may yet be something clever
>       that could be done with broadway; I'm probably wrong, but it
>       feels like a string I should tug on.
> 
> 
> 
> I did discard the concept of a Flash client; I feel that's not really a
> good long term solution.
> 
> So all that leads me to conclude that the best path forward would be a
> Javascript / HTML5 client implementation.
> 
> So now, please bring out the clue bats!
> 
> 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 :)

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

And the main problem:
 * no one stepped up to write one.

> 
> Other thoughts?
> 
> Thanks,
> 
> Jeremy
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel