[Spice-devel] Alternate platform exploration

[Jeremy White]

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?

Other thoughts?

Thanks,

Jeremy