[erlang-questions] Newbie training project proposal

[Joe Armstrong]

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.

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)

<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)

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 :-)

</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.

Have fun

/Joe Armstrong


On 9/11/07, Brian McCallister <brianm@REDACTED> wrote:
>
> On Sep 10, 2007, at 2:18 AM, Tomasz Błachowicz wrote:
>
> > Hi all,
> >
> > I'm looking for wannabe/newbie erlang developers who'd like to learn
> > that language in practice. I'm going to create new open source project
> > from scratch that will aim to implement STOMP messaging protocol [1]
> > in erlang. I've been considering both client and server side
> > implementation.
>
> I'd like to jump in too. Am an okay general programmer, but quite new
> to erlang.
>
> -Brian
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions