[Erlyaws-list] Support for haXe 2 remoting (patch)

[Tomas A. <tom...@gm...>]

Hi,

	attached is yet another patch, this time for haXe.

It seems the serialization in haXe has changed a bit
since 1.0. Particularly the following tags:

- s now seems to mean a base64 encoded binary sequence of bytes
- y is now used for strings, and it is url-encoded utf8.
- j is no longer utf-8 with backslash-encoding of \r and \n.
    It has changed to denote an enum.

So attached is a patch that updates the yaws/src/haxe.erl to
support (currently only, see below) the encoding in haXe 2.

I've successfully run it with with arrays of strings with debian's
haxe 2.1.

Since the patch/change is a bit large regarding haXe, so I guess
people might have opinions or concerns. Here are some of mine:

One concern is how to select the right decoding/encoding version:

I could not find anything in the haXe remoting that specifies the
encoding. The HTTP headers says: "X-Haxe-Remoting: 1\r\n", same
as before, and the payload still starts with "__x=".  So I guess
this means it is up to the application programmer to know whether
her/his client use the haXe 1 or 2 encoding.

I guess this would mean that the haXe version number would
somehow have to be specified in the code from the yaws-page in
the call to yaws_rpc:handler(Arg, {?MODULE, Function}).

How is this best done? An extra optional parameter to
yaws_rpc:handler? Another field in the Arg? An optional 3-tuple
{?MODULE, Function, Opts}? Or someting else? (I think none of the
alternatives look too good...)


Another concern is the actual version number itself:

It seems the haXe remoting has undergone some evolution. This is
what I found out:

- The y tag was added in haXe 1.11
- The j tag was redefined in haXe 1.16
  to mean enum instead of backslash-encoded utf8
- The s tag changed to be base64 encoded in 2.0

(This is all according to the prominent comment in Serializer.hx
that describes the tag characters, for the different cvs tags.)


The patch introduces only two versions: 1 and 2, while in
reality, there seems to be a lot of versions in between.
The version 1 encoding/decoding in the patch is just like
what haxe.erl did previously (= without the patch).

Version 2 is the default, but we'd need extra support to be able
to specify version 1, see above.

Is it ok to have only these two versions now that haXe 2 is out,
or would we need all those versions in between? (E.g: Debian has
haxe 1.19 in unstable while 2.x is still only in experimental.)


Some more minor concerns:

The encode/2 and decode/2 now takes a list of options as second
parameter.  Previously they had an otional second boolean
parameter. This still works, but I think the options-approach is
to be preferred. So there are now two options: use_cache and
haxe_version. Should we still keep the seond-parameter-boolean
alternatives? (only a few lines of code, so perhaps not much to
argue about.)

The decoder can work on continuations, but this seemed to not be
used by yaws itself anywhere and the tests didn't cover it. I
think I got it right, but in case anyone has code that calls
haxe:decode/2 directly with continuations, we might have to
verify this closer.

I chose a binary rather than a string would be the proper
representation for the version-2 "s"-tag (the one that's base64
encoded).

The test cases in haxe:test() now pass (well, maybe this is nothing to
be concerned about :-) ). I had to change some parts in how the old
encoding/decoding of utf8 (the j tag) to make the old tests pass.

BRs
Tomas