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.
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.
So, I think we need to discuss how we're taking the .NET client forward
including:
- identify what the key differences between the client implementations are
(beyond protocol versions etc)
- discuss migration paths for existing users
- version negotiation/future proofing ?
I think the supported APIs are particularly relevant for these last two
items (API differences are probably a big part of the first item also).
- testing, including the interop test runner integration
I've been meaning to comment on this more generally.
The examples that we have in python, c++ and JMS have been another way
of testing interoperability between clients. I think they currently
probably have at least as good coverage as the defined interop tests
(though at present the python examples are 0-10 only).
There are scripts for automated runs of the clients against each other
in all combinations. (In fact, we run the python and c++ ones as part of
the c++ 'make check').
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?
- active commiters/contributers for the .NET
- known use cases we should address
This might be a good question to ask on the user list.
At the end, I'd like us to have a strategy we are all happy with and a clear
development roadmap for .NET users.
Ideally this session would also allow some of our new windows developers to
get involved and to influence what we're doing with the client.
I think it would be worth opening up some specific email debates on this
list and/or the user list. That doesn't prevent any telephone
conversations, but I think an email thread will have wider participation
and will consequently be a useful source of input.
Hope this sheds some light,
Yes, very helpful. Thank you!
