qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Skinner <aidan.skin...@gmail.com>
Subject Re: Accepting large contributions (was Re: 10000 msgs limit per session)
Date Thu, 03 Dec 2009 22:37:36 GMT
On Thu, Dec 3, 2009 at 10:11 PM, James Mansion
<james@mansionfamily.plus.com> wrote:

> Aidan Skinner wrote:
>> It's particularly important where we're importing something which
>> duplicates (fully or partially) existing functionality, if only so
>> that the situation is sufficiently clear to people trying to make an
>> informed decision about what best suits their needs.
> Perhaps the QPID project itself could focus on just C++ for all the protocol
> handling and use swig (or similar) to create wrappers, so the code volume to
> support multiple client languages will be much smaller.  Then native clients
> can be completely independant projects.

Eh, I don't really want to get rid of the actively maintained clients
we already have. In particular, Java and C# derive enormous benefits
from purely managed code in terms of portability, JITability etc.

Having said that, I can see definite value in a C wire library and
autogenerated bindings using something like swig or
gobject-introspection. C++ is a *total* pain to bind.
Gouge-your-eyes-out bad.

> AMQP is supposed to be interoperable on the wire: there shouldn't be a
> requirement for QPID to provide a lot of native client support, though some
> scripting (for some definition of that term) is clearly handy for testing
> etc.

Yeah. I don't really want to get into a situation where people send us
INTERCAL clients and we commit them.... ;)

- Aidan
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire

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

View raw message