[Spice-devel] Alternate platform exploration
jwhite at codeweavers.com
Wed Mar 28 10:05:33 PDT 2012
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,
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
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
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,
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
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?
More information about the Spice-devel