[erlang-questions] JSON/EEP/critical discussion

[Enrico Thierbach]

Hi list,

as someone pointed out
(http://fullof.bs/prototype-eep-18-considered-harmful-the-problems-with-erlang-to-json-term-translation#more-402
and http://sc.tri-bit.com/outgoing/scjson%20parser%20halp.html) some
people seem to have issues with EEP0018's current state.

Despite that I will continue working on a native JSON<->Erlang
implementation. However, my original intention is to support couchdb
with such a thing. Chris was kind enoug to point me towards the EEP,
which I believe to be an excellent help for  the implementation.
However, I don't care much about whether or not what I am doing will
end up in the Erlang distribution. I will still try to stick to the
EEP for most design decisions, so that my code might be turned into a
part of OTP at some point. I will try to be flexible enough with what
conversions occur at what point: if need arises we should be able to
change such things pretty quickly.

Most issues pointed out in the above text relate to roundtrip
conversions (i.e. take some term, convert it to json, convert it back,
and please get an equivalent term). In difference to that post I don't
feel the necessity of supporting feature complete round trip
conversion for all kind of terms. After all JSON is not and was never
intended to be a format for the representation of all kind of data; it
is intended as a lightweight human readable and editable format for
interchange of structured data. As such it only supports a limited
wealth of data types, and it must do so - otherwise it would limit the
# of environments that can be able to fully support JSON. (Or how
should a C JSON reader deal w/a Erlang function?)

In that light I second the notion that the naming (term_to_json,
son_to_term) might be misleading. Users *might* expect a feature
complete conversion. Of course if a user needs a complete conversion
for transmission purposes he/she should just use term <-> binary
conversions. But of course choosing different function names might
surprise less (json:from_json/1,2 and json:to_json/1,2 come to mind).

So long, I will keep you posted re/the implementation progress.

/eno

PS: Talking of round trip conversions: http://sc.tri-bit.com/outgoing
does some weird things with spaces in the URL, ending up with an
illegal URL in the browser's URL line. Is that behaviour intended?
-- 
====================================================================
A wee piece of ruby every monday: http://1rad.wordpress.com/