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 att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk On Wed, Mar 28, 2012 at 7:05 PM, Jeremy White <jwh...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel >
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
