Rajith Attapattu wrote:
IMO it's not a very accurate picture.
Well, we can debate whether the assortment of protocol support levels
actually
has that affect, but its not really important.
Having said that, there would still be quite a bit of work maintaining
them and we would need an owner/maintainer to champion a client to
ensure that end user needs are properly met.
From my pov the whole point would be that 'maintaining them' becomes
'somebody
else's problem'.
You need to maintain the core swig centrally and allow feedback from sip
etc devs to
shape the raw API, but beyond maintaining enough code to ckeck that its
working (and
that definitely does not need to use platform idioms - and is a side
effect of testing the
core anyway so little extra effory) thats job done.
The total effort is still great - sure - but the steering and release
management of the
core is much more focussed.
I definitely agree that a passive state-machine implementation of the
protocol core is the
ideal. In the case that its 'too hard' then some sort of abstraction
similar to the OpenSSL
BIO might be adequate, at least up to a point.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
