Middle men wanted
Wed May 5 16:31:55 CEST 2004
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> 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
raw data gathering -> HTTP parsing -> SOAP parsing -> ...
> 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:
> 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.
More information about the erlang-questions