qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: IKVMing the Java client for .Net
Date Mon, 02 Feb 2009 21:22:34 GMT
I think a key point in our decision making here, one we have not always
given enough importance to, is the needs of our existing users. A few of
them bend my ear, so here goes ....

Qpid has been going for quite a while now, and we have many existing users
who have deployed a Java Broker and are using the .Net/Java/C++ (old)
clients to talk to it. We need to avoid creating situations where these
users are forced to upgrade their broker to use our clients going forward.

Interoperability is really important, and will remain so for the next 12
months. Not all implementors of AMQP will be at the same version as quickly
as others. Backwards compability remains a significant advantage for our
users. and one we should strive to keep.

On the Java broker side, we currently have no-one (unless I missed it)
declaring that they're working on 0-10 for M5. Is someone planning to do
this, firmly ? I think this has bearing on my (and other Java-ers) views
here of the short-term/medium-term requirements.

On Mon, Feb 2, 2009 at 4:37 PM, Carl Trieloff <cctrieloff@redhat.com> wrote:

> Aidan Skinner wrote:
>> On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff <cctrieloff@redhat.com>
>> wrote:
>>> Only supporting 0-10 means it won't talk to the current Java broker or
>>>> any of the other AMQP implementations such as OpenAMQ or RabbitMQ.
>>> Does that really matter, we already have an 0-8 client for .NET and
>>> others
>>> exist. We need to look
>> I think having a client which can interoperate with 3 of the 4 AMQP
>> brokers I know of is quite important. The existing 0-8 .Net client is
>> somewhat suboptimal and doesn't support any standard API.
> I believe that should drive our technology selection. That is something
> that will change with the
> political landscape. What does not change is that we will need to maintain
> the client for many years. I
> think we should work out the optimal solution for .NET (Windows) as the top
> criteria for technology
> selection.
> Carl.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message