OTP or not to OTP

[Jay Nelson]

Adding in the max connection count for accepts has caused
me some problems.  Once you start counting them, you must
have everything linked or you won't know when the children
go down.  Asynchronous processes end up off in their own
world, while the gen_server's state is being updated.  When
the asynch process needs to change state it can't because
it is out of synch.  Also, I do have to worry about which
processes can fail or not, so OTP didn't reduce any of the
thinking or subtlety of the issues.

I am starting to understand what Jocke and Joe are saying
about OTP.  If you know it inside out, you probably wrote it
and can work with it (or change it).  If you don't and you hit
your head, you are struggling against OTP not erlang.  Once
you take the leap and roll your own, you can modify it any
way you want and you have finer control over issues like
synchronization and state.

I wouldn't have considered doing it from scratch without the
examples posted here in the last few weeks.  It also took me
struggling to fit the concept into OTP to see where there are
issues (there is a single gen_server state that must be
updated synchronously -- asynch processes have to deal
with that).  It feels like centralized management when I had
the original impression that it was more like decentralized
management.  Chris's new server / client library looks pretty
clean (as does his whole toolbox approach).

On a team project I would want a standard that everyone adheres
to and a separate architecture group.  It is very easy to get
something 90% in erlang, but that last 10% has subtle issues.
The simplicity of the code belies the issues that it solves.  Of
course, in another language I wouldn't get far enough on a
distributed problem to realize the issues that occur.

I may not be able to post my example today.  I still have to work
out the max connection issues clearly.

jay