On Thu, Jan 8, 2009 at 11:25 AM, Gordon Sim <[email protected]> wrote: > Marnie McCormack wrote: >> >> We have (to the best of my knowledge) no requriements spec for either >> implementation, functional or non-functional. > > I think the basic requirement for a client is to allow a user to exploit the > features of the protocol version in question.
I think that's certainly important but I think having a stable, idiomatic API is perhaps more important. I think this is particularly important until AMQP stabalises, given the changes between 0-8/0-9, 0-10 and the proposed 1-0 drafts. It would be very difficult to write an application which talked all three, and often all you want is "put message on queue A, get message from queue B". Having access to the underlying protocol is certainly necessary for some applications, but I think it's something we should be discouraging generally and providing means to avoid where possible. > There may be other relevant APIs for particular languages, so e.g. for .Net > WCF support might be an additional requirement. Of course there may then be > more detailed requirements about the mapping from the API in question to > AMQP. I think System.Messaging is probably more relevant to .Net, this is the route that Mono has gone down with ActiveMQ and RabbitMQ: http://www.mono-project.com/SystemMessaging (there was also an attempt to implement it on top of our 0-8 client but that didn't work out). > I was very much in support of the interop framework approach, but with the > benefit of hindsight, the simpler approach followed in verifying the > examples has I think ended up being more successful. > > We are always going to want to have examples to show users how to do various > things; we need to run those regularly in all combinations to ensure they > all work. Using that same approach for testing interop between clients feels > like worthwhile conservation of energy. > > Thoughts? The framework is a good idea, but is somewhat poorly implemented. I'd be quite interested in a generic system which took test cases in xml and ran them using the implementation of choice. I think OpenAMQ may have something similar. At the moment adding a test case is a lot of work and ends up being duplicated across the different implementations. This is a more general discussion though, we should probably start a seperate thread. >> - active commiters/contributers for the .NET >> - known use cases we should address > > This might be a good question to ask on the user list. Definatley. We have a few active users and contributors to the .Net client. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org
