[erlang-questions] Newbie training project proposal

[David Mercer]

On Tuesday, September 11, 2007, Joe Armstrong wrote:
> Do protocol designers turn off their brains when they design protocols?
> 
> I see a lot of the following:
> 
>    - text protocols with are "easy" to understand and parse
>      (false - most text protocols are inadequately specified)

One advantage of text protocols is that you can telnet to a port and do a
transaction manually.  I'm thinking SMTP and HTTP here as examples.  I have
on occasion had to send email without a mail client handy, so I just telnet
to port 25 of my mail server and type in the SMTP commands.  Similarly, I
have had occasion to need a web page without a browser handy: I just
telnetted to port 80 and typed in my request.

STOMP is very HTTP-like.  We'll be able to interact with the STOMP server
with nothing but telnet and a keyboard.

>   - XML protocols
>     (crazy - did anybody think how long it would take to parse this crap)

I agree with you wholeheartedly on this one.  It's convenient for XML shops,
but as a basis for a protocol that might be used by multiple organizations,
it's a waste of resources.  Non-XML shops end up having to do a bunch of
string manipulation, regexp searches and the like to manage XML, which is
awkward, buggy, and annoying.

> 
> The two most obvious methods for building protocols are:
> 
>    - define a packed bit-byte-word structure appropriate to you needs
>    - use serialised lisp S expressions, or Erlang terms (whatever)
> 
> Are rarely used.

Agreed.  I probably prefer S-expressions as the most generic.  Even though
they are very Lispy, they are ridiculously easy to parse in any language.
Erlang terms are up there with JSON: they are kind of locking you into a
technology, but they're not too difficult (or verbose) for
non-Erlang/Javascript shops.  At least they don't come with all the baggage
of having to handle external DTD's, matching closing and opening tags,
handling attributes and namespaces, and so on.

Cheers,

David