Rupert,
> Might it be an idea to hold/complete the discussion on uniformity > accross > clients, before solidifying the choices made into Java code? > > It seems to me from the .Net API discussion that the following are the > most > favoured choices: > > WCF -> Qpid AMQ API -> framing > JMS -> Qpid AMQ API -> framing > > I had some questions about possible efficiency issues around too much > layering, but as the Qpid API maps so closely onto the AMQP protocol > that > the middle bit is perhaps little more than some convenience methods, > that > you might write anyway, to build and dispatch frames to/from the event > framework and framing layer that needs to be there regardless of the > API > choice. > > Do we need/want/have the will/time to expose a common Qpid AMQ API > accross > all clients? If we want uniformity, and some choices and changes are > currently being made as to what the .Net API will look like, it would > be > prudent to reach a concensus first, or else we will just end up with > two > more non-uniform APIs. I agree this is a valid question, but at least from my point of view, uniformity of the API isn't such a big deal, for this kind of project in particular. That said, if the API were to be that AMQP-compatible API, which is certainly fairly low level, then by that virtue alone the API would be fairly similar across implementations, simply because it would resemble the AMQP class/method model fairly closely. I believe we'd likely still have some differences for things async operations (which definitely have different conventions across languages), but that wouldn't be that bad. Personally, I think this is a good thing, and I'd vote +1 on creating this lower level API. Seems like 0.10/0.11 might be a good time to do it given the changes in sessions/channel and framing, but what do I know :) Also, just for the record, from the .NET client side: Sure, it would be nice to have a WCF channel for Qpid; in fact, it's something I've in mind for a long time, and even made some initial implementation. However, having a lower-level, alternative API would still be a good thing, for several reasons: 1- Not all people will want to use WCF, for example, we might want to provide native BizTalk adapters as an alternative. 2- WCF limits what the API can do, simply because the surface it exposes to the application/service is limited to the messaging operations (i.e. send/receive). There's really no clean way of exposing the other AMQP API's to the application/service to do things like create a queue on demand, or create an exchange. In the initial WCF channel implementation I did, I worked around this by using configuration properties that provide support for common operating models. For example, it might be common for a message publisher to declare the exchange it will publish messages to, so it could set a property on the binding telling it to declare the exchange (alongside with the exchange name and class properties) when the client channel is opened. Now, this is a good compromise, I think, but it still is a compromise. > Also, what are we to make of the new Java client? I'm a bit unclear as > to > why it is being written in a completely seperate module as a clean > re-implementation. I can't really comment on this, but I do have an opinion regarding it. I've become very familiar with the Java client code (as well as the .NET client code) over the past few months, and in my very humble opinion, a lot of the code is a mess. Not only is it complex, it is also hard to test and it has a number of poor practices that make it even more complex: Classes too big (just look at the connection or channel/session classes), very tight coupling between classes at different layers and an arcane threading model (i.e. MINA in the Java code, and unfortunately the original .NET code got stuck with the same model, even though it doesn't have the MINA restrictions). This not only means the code is harder to maintain (again, imho), it is also more fragile and inefficient (and the multitude of threads it creates here and there to work around the base threading model makes it "steal" valuable resources from the application/service using the client). Personally, if it were up to me, and we agreed on creating the new lower-level API, at least for the .NET client I think the right choice would be to rewrite a large part of the client code base. A lot of this will be necessary anyway with the changes in 0.10/11, anyway. That said, the lowest levels of the stack work pretty well, imho (i.e. things the model for the lower level framing layer and coding/decoding and the transport layer). Just to put it in context: I was pretty surprised (and not in a good way) to realize that I was able to follow the C++ client code base much easier than the java (or .net, for that matter) code base :) Tomas Restrepo http://www.winterdom.com/weblog/
