qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Skinner <ai...@apache.org>
Subject Re: IKVMing the Java client for .Net
Date Mon, 02 Feb 2009 10:33:05 GMT
On Fri, Jan 30, 2009 at 6:11 AM, David Ingham
<David.Ingham@microsoft.com> wrote:

> Carl's right, we have been investigating the idea of layering a WCF channel implementation
on top of the C++ client library. That is, the managed code channel implementation would pinvoke
down to the native C++ code. This is the approach that we used for the MSMQ channel that ships
in the .NET framework today and it works pretty well. We're drawn to this approach primarily
because of the maturity of the C++ code base. The pure .NET approach clearly has merit too;
one of the key advantages being that it offers the potential to factor the code in a way that's
more in line with WCF best practice, i.e., as a set of layered channels rather than as a monolithic

Doing it on top of the C++ client has two current disadvantages over
the Java client that I can see:

not 100% managed code
only supports 0-10

Not having all managed code reduces portability (since you're now
limited to the platforms that the C++ client supports) and limits the
security profiles that the client will run under.

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.

Related to this, it seems likely that the Java client will support
AMQP 1-0 before the C++ client does, if only because the Java client
already supports multiple protocols.

On an unrelated note, what do you mean by the "the maturity of the C++
code base"? What about that client made it a better choice from your
PoV than the Java client?

- Aidan
Apache Qpid - World Domination through Advanced Message Queueing

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message