[Spice-devel] Javascript client update, next steps

[Jeremy White]

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.

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.


  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.


  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?


Cheers,

Jeremy