I think we ran a bit off topic here - mainly due to my fault. Can we focus again on the specific JMS issue.
Andrew do you have concerns/comments based on my last reply to the questions raised by you? In summary what I mentioned was, * That I agree that we need some sort of refactoring along the lines you proposed regardless of what I am proposing. But I doubt that alone will help in what I am trying to achieve. * I agree that we need to keep in mind that this mechanism should cater to a variety of situations like integration/embedding in containers like spring,app servers, third party apps, external JNDI mechanisms etc.. * That I am not so keen to promote what we have now (Ex. AMQConnectionFactory) as the public API for a variety of reasons outlined in my response to yours. * That we need to have some sort of "Simple" and "Stable" API for this, especially knowing that our client will be undergoing a lot of changes in the near future, especially with work related to AMQP 1.0 etc. Regards, Rajith On Fri, Feb 11, 2011 at 2:09 PM, Andrew Kennedy < [email protected]> wrote: > On 11 Feb 2011, at 15:24, Rajith Attapattu wrote: > >> On Thu, Feb 10, 2011 at 2:11 PM, Gordon Sim <[email protected]> wrote: >> >>> On 02/10/2011 02:54 PM, Rajith Attapattu wrote: >>> >>>> The above is not a formal authoritative document that describes what our >>>> Common API is. >>>> >>>> If by authoritative you mean '100% accurate and complete' then I accept >>> it >>> is not there yet. >>> >>> >> Actually by authoritative I didn't really mean accuracy and completeness, >> rather I was expecting a document in a different form. >> Perhaps something similar to the JMS spec. I believe you and I have a >> different vision about how this document should look like. >> Perhaps that is where the disconnect is. As time permits I will try to >> work >> out a document and post it to provide a more complete picture of what I >> was >> envisaging. >> > > *Please* don't repeat the mistakes the JMS specification made! I really > feel it's too vague and wooly for a formal specification, whereas it ought > to be precise and informative. There are too many situations where I have > checked the JMS specification, only to find it describes behaviour that > could be interpreted in several different ways, or worse is simply undefined > or up to the provider. This style is more suitable for a programmer's guide > describing the common API, covering the technical terms of reference, design > philosophy, illustrating common use cases and giving concrete examples of > code. This type of document was (the first) 2. on your list and 4. on mine, > assuming your list to be describing six different types of document. > > I still think UML is a concise and reasonable way to model the AMQP common > API in a language agnostic fashion. This is document 1. in both our lists, > and it MUST have a well-defined correlation with the official AMQP > specification(s). > > Take a look at Enterprise Architect (very good, I used it a lot at Yell for > data modelling) or the Eclipse modelling tools (never used in anger) for UML > design tools. To be hones, I think UML is probably too powerful when it > comes to describing AMQPs data structures and commands, but that should make > the task easier. It has the benefit that any competent programmer can > mentally translate between UML and $FAVOURITE_LANGUAGE, and there are tools > to automatically create HTML documentation or Java, C++ or whatever code > templates. > > > Andrew. > -- > -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ; > -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ; > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
