[Spice-devel] Javascript client update, next steps

Alon Levy alevy at redhat.com
Sun May 6 01:37:29 PDT 2012


On Thu, May 03, 2012 at 10:16:01PM -0500, Jeremy White wrote:
> I've got a pure Javascript based client with which
> I can control a few xterms, start and use gedit, and just generally
> operate an Xspice server.  It's still extremely limited; a few kinds of draws, no
> masks or clips, no authentication, and only quic images.  It's slow,
> and the mouse movement is completely unoptimized, so you can
> quickly make it look bad.  It's also nice and buggy.
> 

Fantastic!

> But it is quite promising - I've run it both locally and
> across a WAN, and I've been tantalized - the concept seems to
> be proving out nicely.
> 
> There have been a few bumps - I had to switch to Firefox (from Chrome),
> and Safari doesn't support a feature emscripten requires.  It's also
> clear that this HTML5 stuff is really quite cutting edge; we
> probably couldn't have done this even a year ago.  However, the
> bumps don't feel like road blocks.
> 
> I'm thinking I'll tidy it up a bit and then go ahead and submit
> it to the project; it's not a lot of code, and it is far enough along
> that it's probably going to be useful to someone else.
> 
> However, to make a complete solution, I'm using the WebSocket -> TCP gateway
> websockify (https://github.com/kanaka/websockify).  It's not very
> satisfying, and I had to hack it quite a bit to add a binary
> protocol layer.
> 
> So I was thinking that first I'd modify the spice server to support
> WebSocket directly (http://datatracker.ietf.org/doc/rfc6455/?include_text=1).
> 
> So, questions:
> 
>   1.  Would this be an offensive change?  The WebSocket protocol
>       is simple, but invasive; all data being received has to be 'masked',
>       and all messages have to be sent as length proceeded messages.
> 
>       Anyone willing to mentor me through this, and/or do the work?
>       I've already demonstrated a lack of understanding of this code <grin>.
> 
>       A straight forward alternate is just to tune up websockify
>       (or similar, there are several such projects) and document it's use
>       in conjunction with the spice server.

I actually started looking at adding this to the server, I think it's
not a trivial amount of work but not too much either:
 - need to add the header negotiation (we already have two flows,
   regulat and SASL, this will be a third).
 - need to implement a third pair of read/write functions (already have
   passthrough and ssl).

How will this work with ssl btw? does websocket support a ssl version?

> 
> 
>   2.  Is there an easy way to activate the audio or video streams,
>       ideally from an Xspice test bed?  I'd like to see if those
>       streams can be supported by the modern html5 browsers.

There is no video stream, all video data is passed through the display
channel (maybe we'd want to change that in the future though).

You should already be able to trigger video just by playing a video on
Xspice (as long as it is larger then some minimal size after 20 frames
it will be sent as a mjpeg stream)

Audio is harder, still TODO for Xspice, nothing there yet. You'll have
to setup a vm with spice to check that out.

> 
> 
>   3.  What other tests am I missing?
> 
>       I mean, *I* think that if you can run an xterm, you've got
>       all you need <grin>.  But other people are fussy about their GUIs.
>       I know I'm only implementing a fraction of the overall
>       protocol, and I can see a big stack of todos (jpeg, regular lz,
>       sasl, and so on), but nothing leaps out as prohibitive.  I'd
>       really like to feel like I've got my arms around most of
>       the issues by the time I'm done working on this.  (I've got
>       about another two weeks I can invest :-/).
> 
>       So what other areas should I probe - what would you expect
>       to be hard or flat out impossible in  a web client?

Video comes to mind as needed, not impossible or hard - you'll need to
decode jpeg (you said you only do quic so far).

copy paste (for this you'll need a vm with spice since Xspice doesn't
have the agent part implemented) is again important (imo), not hard.

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


More information about the Spice-devel mailing list