On 07/20/2012 06:41 PM, Rafael Schloming wrote:
On Fri, 2012-07-20 at 11:20 +0100, Gordon Sim wrote:
On 07/19/2012 07:03 PM, Alan Conway wrote:
On the blocking front, a good messaging API should support both blocking
and non-blocking use. The messaging API can certainly be extended in a
backward compatible way to do so.
Yes, I agree.
On the easy-to-use front it seems to me that the ideal is the an easy
messaging API layered over a full-control proton API, where the
underlying proton API can be exposed for "advanced" users or ignored by
normal users.
I think there are perhaps more than two levels of ease of use. At the
very 'top' level, you just care about sending and receiving with no
interest in connections, sessions, sender or receivers. The 'bottom'
level is full protocol control. The messaging API at present is
somewhere between those.
I don't actually think of the "Limited" column of the matrix, or any of
the others as expressing easy vs hard. The matrix is classifying what it
is you want/need to be able to do, not how hard it is to do it. Ideally
functionality in every quadrant should be as easy to use as possible.
Agreed, I should not have used the term 'ease of use'. Its really about
the level of abstraction from the protocol interaction.
Given that it's describing functionality, you could certainly define
more columns based on a finer grained look at the protocol features that
are available, and indeed there are different aspects to the two
programming models that may ultimately make sense to call out into
different rows. What I've included represents the extreme ends of the
spectrum in each dimension, as that's where initial work has been
focused in order to ensure the necessary flexibility.
Right, the most limited set of functionality that still makes sense is
simple sending and receiving messages (no explicit connections,
sessions, senders, receivers).
At the other end of the spectrum you have full control over all aspects
supported by the protocol.
In some ways there is increasing 'functionality' as you move away from
direct interaction with the protocol. E.g connection pooling, perhaps
transparent replay etc, However you also get less control over the
protocol, which may in itself be a loss of some functionality.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
