[Spice-devel] Alternate platform exploration

[Attila Sukosd]

Hi Guys,

I've also been contemplating an alternative html5/js client, and as far as
I remember, Alon proposed an extension to spice-server to actually contain
a http server to serve the content to the browser.
But it seems like a too big project to take on alone :)


Best Regards,

Attila


-----------------------------------------
DTU Computing Center - www.cc.dtu.dk
attila at cc.dtu.dk, gbaras at student.dtu.dk, s070600 at student.dtu.dk




On Wed, Mar 28, 2012 at 7:05 PM, Jeremy White <jwhite at codeweavers.com>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?
>
> Other thoughts?
>
> Thanks,
>
> Jeremy
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20120329/31596769/attachment-0001.htm>