qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner" <ai...@apache.org>
Subject Re: Qpid .NET Strategy - Interested ?
Date Thu, 08 Jan 2009 12:58:07 GMT
On Thu, Jan 8, 2009 at 11:25 AM, Gordon Sim <gsim@redhat.com> 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

Mime
View raw message