[erlang-questions] Newbie training project proposal

[Tomasz Blachowicz]

Hi Joe,

On 9/11/07, Joe Armstrong <erlang@REDACTED> wrote:
> This project (and actually the way of working) sounds like a
> good way to learn Erlang. If you like I can act as a "mentor" and
> give you some advice with your code now and then.

That's really cool! Frankly speaking I couldn't imagine better
"mentor" than language creator :) Thanks a lot for volunteering.

> I'll start with a little rant about the architecture of STOMP :-)
>
> Here beginneth the lesson
>
> One fun thing might be to *extend* the protocol with a layer that
> allows the end-points to
> negociate the transport format.
>
> Here's the idea:
>
> Client -> Server
> HELLO
> ICanSpeak: Stomp,erlangTerms
>
> Server->Client:
> HELLO_RESPONSE
> erlangTerms
>
> Thereafter the two sides could communicate using serialised Erlang terms
> (made by term_to_binary(Term)) and its inverse.
>
> Then you just use the lib_chan in appendix D of the Erlang book (shameless plug)

I haven't even considered to use erlang terms internally. My OO brain
need some more exercises :) I need some time to get the idea, to be
honest. But the idea seams pretty clear to me. My background is Java,
so I didn't considered native 'serialization' which is discouraged in
such cases in Java world.

> <flame on>
>
> 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)
>   - XML protocols
>     (crazy - did anybody think how long it would take to parse this crap)
>
> 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)

I'm not a big fan of STOMP design, either. I believe its
String-orientation is the main flaw. On the other side I understand
that STOMP is designed as general purpose protocol with
interoperability in mind. I recon, binary application layer protocols
are hard in terms of interoperability, because Java or Python client
don't understand Erlang or lisp serialised structures.

> Are rarely used.
>
> A pure Erlang version of Stomp would look like this:
>
>     Server ! {connect, user, PassWord},
>     receive
>           {Server, {connected, SessionId}} ->
>                 ...
>     end.
>
> Now when you write your code you should use the technique of a "middle man"
> this is a process that converts Erlang terms to the format of data you
> will see "on the wire"
>
> If you send the message {connect, User, Pass} to the middle man
> it will send a
>
>    CONNECT
>    login: <username>
>    passcode: <passcode>
>
> message to the socket
>
> Something like
>
>       middle_man(SourcePid, DestSocket) ->
>               receive
>                       {SourcePid, {connect, User, Pass}} ->
>                               DestSocket ! [<<"CONNECT\nlogin:">>,User,
>
> <<"\npasscode:">>,Pass,["\^@"],
>                               middle_man(SourePid, DestSocket);
>                        ...
>
> This method (by extension) gives you a modular way to swap out the code in the
> back-end (you could use erlang terms, xml, or even STOMP :-)

Good point. I believe we have to adopt your idea. I need write some
code to see how it works, any way :)

> </flame>
>
> Here endeth the lesson
>
> Secondly documentation - code is NOT documentation - never was never will be.
>
> Code is what the machine does - documentation is what it is *supposed* to do.
>
> In a well written system the code does what the documentation says it
> is supposed to do.
>
> In a badly written system there is no documentation and we have no
> idea what the code is supposed to do since we only know what it
> actually does - then we have to guess
> what it was supposed to do.

This is what every mentor should include in the his or her
introductionary post :)

> Have fun

I do have a lot fun coding this stuff :)

Thanks again,
Tom