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. 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. --Rafael --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
