Aidan Skinner wrote:
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".
Yes, I agree that a high level interface to the basic operations that
remain unchangeable is very valuable. My point wasn't meant to imply
that a client must expose the protocol in all its gory details, but that
the basic purpose of any client code is simply to exploit some feature
of AMQP (e.g. sending a message).
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.
Agreed.
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'm pretty ignorant of both WCF and System.Messaging; my comment was
really just an example of using an existing and applicable API where one
exists. This seems like another good point to discuss on the user list.
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.
While I see the attraction of this, I'm not convinced it would be
successful in practice. It ends up being the design of a new xml based
messaging language and I foresee new tests continually coming up against
limitations in that language.
Automated runs of example programs has the benefit of allowing the
example to do anything that can be expressed in the client language with
the API offered.
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.
Yes, and since some effort is expended on examples anyway, and those can
be used to verify interop as well, duplicated work is even less attractive.
This is a more general discussion though, we should
probably start a seperate thread.
Agreed.
