This is great! Let me start by saying that we are planning to send Erlang Term Format from channels in Phoenix v1.5, as that will use less CPU and save bandwidth. So work on this is definitely welcome as well as an efficient decoder in JS (the client will continue sending JSON though).
With that said and since you are planning to drop RPC anyway, I would call it SETF - Sequential Erlang Term Format. It is sequential because it does not include PIDs and others.
With that said, my take is:
- Should we support atoms?
Yes.
- Should we support byte lists (aka Erlang strings)?
They should just be a list of integers. I.e. they should not have a special treatment. (btw, Erlang strings are a list of chars)
- Should we allow defining improper lists?
I am personally indifferent.
