On Thu, 2012-07-19 at 14:03 -0400, Alan Conway wrote: > On Thu, 2012-07-19 at 15:59 +0100, Gordon Sim wrote: > > > > I've personally invested a lot of time and effort in the qpid messaging > > API. It was specifically geared to transitioning to 1.0. I personally > > feel there is much to recommend it still. My desire would be to find a > > way for this to 'blend in' with the APIs developing under proton in some > > way. > > > > However I agree with Rafi's analysis of the different facets of use; I > > find his account of the evolution of proton in this respect compelling. > > I think it would be foolish to stick rigidly to the past despite a > > deeper, richer understanding of the API space emerging. > > > > I believe that what users really want is not 4 entirely separate APIs, > > but something that transitions from one use case to another more > > smoothly. Ideally I don't want to have to learn all 4 APIs to see which > > one best fits my requirements; ideally I don't want a new requirement in > > relat > > my system to force me onto an entirely different API. > > > > Rafi's axes were blocking/non-blocking and > easy-to-use/full-control-of-protocol. > > 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. > > 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.
As I mentioned in my reply to Gordon, I don't think of the "Limited" column meaning easy-to-use per/se (although there is obviously some correlation), I would think easy vs hard probably maps as much to the blocking vs non blocking rows, since often people find non-blocking difficult. The key difference in the columns is exposure to the low level details of what's going on. The interface to the messenger API is pretty much just: send(global-address, message) The messenger implementation will under the covers open the necessary connections, sessions, and links required to deliver the messages you pass to it. In interface it's very much like the sendmail program, except it's a lot smarter and more powerful since it does pooling and what not behind the scenes, and of course it can receive messages in a similar way as well with global subscriptions. This is obviously a very different paradigm from say the messaging API or the engine where you have explicit control over exactly what connections, sessions, and links are created and you manage them all yourself. This is why I suspect a complete implementation of the feature space within the matrix may actually be a small suite of integrated APIs rather than a single API. It's hard to imagine a single API that will do both what messenger does and what messaging does, but it's easy and quite useful for both those APIs to use the same message abstraction. --Rafael --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
