One thing that seems to have come up a few times, is the idea that it would be hard to have the same API across different languages. I don't think it would be technically hard to do this. If we assume OO as a base line, and define the API as a class diagram in UML (1:1 the protocol, of course), the mapping onto any OO language is really quite trivial.
All our current target languages for Qpid are OO, so do we really need to care about lack of support for functional/procedural? Even if we do care about them, there are ways that a class diagram can be mapped into non-OO languages anyhow. I think what is hard about this idea, is coordinating the implementation of a common API across Qpid, given that code bases for the different languages are in different states, implement slightly different versions of the protocol, are being worked on by different people etc. Would it be an idea to draw up an API convergence sheet? A spreadsheet that documents by function, the class to which the function belongs, the name of the function and its arguments in each of the languages. Then decide what it is that we are converging towards, then converge? Rupert On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > On 8/22/07, Robert Greig <[EMAIL PROTECTED]> wrote: > > > > On 22/08/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > > > > I do not particularly see the need for an API which is neither JMS > that > > > doesn't look exactly like the model layers of AMQP [that is the API > need > > not > > > expose all the 0-10 features for connection establishment, session > > > maintenance etc... those are functions of the client library and > > shouldn't > > > be exposed to the application programmer - For those familiar with > AMQP > > 0-10 > > > I think the API should provide hooks into all of Layer 4... with > > > abstractions for the lower layers]. > > > > Yes, I agree and would go further. I think it is positively > > detrimental to Qpid to have two "competing" APIs . > > > As I mentioned on the other thread [JMS extensions] there is no competing > API's. > The low level Qpid API and the JMS API targets different levels of users. > If we clearly document the pros/cons there wan't be any confusion either. > > It is confusing to potential users - which API to choose? Remember that a > > large > > proportion of our target userbase is an "average" enterprise developer > > where messaging may only be a small part of the application. > > It is also detrimental to the overall Qpid effort since it is more > > code to support and document, duplicating functionality in our > > extended JMS API. Don't forget the opportunity cost! > > > The JMS implementation is built on top of the low level API. > Hence we maintain only one code base. > There shouldn't be any duplication of functionality. > As Rob describes It's L4 + abstraction of L1-L3 + a few convenience > methods > to help the JMS impl and direct users of the low level API. > Nothing more. > > RG > > >
