On Mon, 2007-08-20 at 12:09 +0100, Rupert Smith wrote: > Onto some ideas about low-level API, what I had imagined such a thing would > look like. I've been hacking this around on my laptop, but without internet > access for it (or time to rebuild my kernel with WiFi support ;-), should > get hooked up at home again on thursday), I will just have to give an > outline of what my ideas look like. I don't like to mail code for something > that I'm not completely satisfied with anyway; yes, my ideas are ideas, > their merit is debatable, and I am interested in that debate to sound out > opinion and shape-up and strengthen the ideas to our mutual satisfaction. I > think this interface/API is an important one, because it is what the clean > modular design of our implementation will hinge around.
You are right we should discuss especially because nobody has ever said that the current proposal was written in stone. > As I mentioned previously I had 3, now 4 criteria: > > 1. Methods as classes, rather than exposed arguments. This is debatable indeed. I am not sure that the performance should disfavor usability and ease of programming. > 2. Full mapping of the protocol 1:1 onto the API. This is again a debatable criteria. I personally think that some convenient features like providing support for connection negotiation would be very helpful. This does not mean that the raw AMQP methods don't have to be exposed though. > 3. Use of the inverse symmetry of the API so that the outgoing interface > that the client calls, is identical to the incoming interface that the > broker routing layer implements. This is a requirement for the common layer and I think that it already does that, doesn't it? > 4. Be language neutral, that is a suitable API for implementing in any of > our target languages. Will assume OO as a base-line. I am not sure that this is realistic and this should be left to AMQP to provide such an API not to Qpid. Arnaud
