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. Marnie On Mon, Feb 2, 2009 at 4:37 PM, Carl Trieloff <cctriel...@redhat.com> wrote: > Aidan Skinner wrote: > >> On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff <cctriel...@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. >
