Middle men wanted

[Joe Armstrong]

On Wed, 5 May 2004, Hakan Mattsson wrote:

> On Wed, 5 May 2004, Ulf Wiger (AL/EAB) wrote:
> 
> Uffe> Perhaps you could add some thinking about how to handle issues
> Uffe> like fault tolerance, in-service upgrade, etc... you know, that
> Uffe> OTP framework that you and some others invented a few years ago. ;)
> Uffe> 
> Uffe> There's not necessarily much discrepancy there, but I believe it
> Uffe> would be helpful to reveal how you've thought about it. 
> Uffe> Proposing a uniform way of reporting unexpected things would 
> Uffe> also be good; in one part of your examples, you use io:format/2,
> Uffe> while in another, you use something called ed_log:error/1.
> 
> This middle man plugin architecture is quite interesting, but why not
> take it a step further and make it independent of the actual transport
> (in this case TCP/IP)?
> 

  Well my middle  men were the things that talked  to TCP streams. For
HTTP/IRC/NNTP/POP3 etc just one layer  works fine and I hadn't thought
any further than this.

  As somebody pointed  out many new protocols (like  SOAP) are layered
onto (say) HTTP - so a multi-tyred approach might be better.

	a chain of processes. In the case of SOAP there could be several
processes involved.

	raw data gathering -> HTTP parsing -> SOAP parsing -> ...

	etc

  Cheers

 /Joe


> In the Megaco application there are three types of plugins:
> 
>  - transport (TCP, UDP, SCTP, ...)
>  - encoding (text pretty/compact, ASN.1 BER/PER, erlang binaries, ...)
>  - user logic (gateway, controller, proxy,  ...)
> 
> The architecture is explained here:
> 
>  http://www.erlang.org/project/megaco/download/LATEST_MEGACO_DOC/html/megaco_architecture.html#2.2
>  http://www.erlang.org/project/megaco/download/LATEST_MEGACO_DOC/index.html
> 
> Even if this application (of course) is biased towards the
> Megaco/H.248 protocol, its architecture is rather generic.
> It was not designed to be a generic man in the middle framework,
> but it almost is.
> 
> /Håkan
>