On Fri, Dec 4, 2009 at 4:18 PM, James Mansion <[email protected]> wrote: > Aidan Skinner wrote: >> >> On Thu, Dec 3, 2009 at 10:11 PM, James Mansion >> <[email protected]> wrote: >> 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. >> > > Well, *some* benefits. There's not much point having jitability and > portability if the result > is that resources are spread thinly and none of the non-C[++] > implementations works > properly. I don't think the functionality and portability story is very > good at the moment.
IMO it's not a very accurate picture. The Python client and the JMS client have very active development. The JMS client have been in production for 2-3 years now. There is a lot of merit in our JMS client being a pure java implementation. It has been used in environments like OpenVMS etc.. mainly bcos Java itself has a fairly decent story for portability. The ruby and C# clients is a different story though and I understand your point about resources being thinly spread. So I definitely think there is merit in a C based protocol engine, and the C++, PHP, Python, Ruby, JavaScript ..etc building on top of that. Having said that, there would still be quite a bit of work maintaining them and we would need an owner/maintainer to champion a client to ensure that end user needs are properly met. > Also, I think the 'native VM only' angle is oversold be zealots. Certainly > in the investment > banking industry its very common to find that quant libraries etc are > written in C++ precisely > because its portable between Java, .Net and so on, so apps with significant > business > logic (ie ones that matter) are infrequently pure VM systems anyway. > > I really don't think there's a problem exposing APIs that look a bit ugly or > non-standard > in the client languages so long as the full API is present - as an enabler > for developers who > care about idiomatic presentation. > . > James > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
