On Thu, Dec 3, 2009 at 10:11 PM, James Mansion <[email protected]> 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:[email protected]
