qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Greig <robert.j.gr...@gmail.com>
Subject Re: 10000 msgs limit per session
Date Tue, 01 Dec 2009 23:54:06 GMT
2009/12/1 Robert Godfrey <rob.j.godfrey@gmail.com>:

>> IKVM is a way of running Java. I have no idea whether IKVM implements
>> enough of the JDK libraries to enable the Qpid Java client to run
>> under it but let's assume for the moment that it does. Further, let us
>> assume that some important change in 0.6 or another upcoming release
>> breaks that. Do we say that we should not proceed with that change
>> because IKVM isn't supported?
> Not quite the same thing is it?  A better analogy might be to imagine that
> the JMS client required the use of the compiled C++ libraries and say we
> only supported Java on Windows and Linux... I think that to have implemented
> the JMS client in that way would have been a poor choice.

Well, my point was that IKVM is a very small niche platform only
likely to be of interest to a tiny percentage of users. While I accept
that mono is a bit bigger than IKVM I'd still argue it's small enough
not to put any special effort into supporting.

As I mentioned, I agree that cet. par a managed code .NET client would
be better but I think the analogy with JMS isn't quite right because
we're starting from a different position. When we built the JMS client
there was no stable C++ client on any platform. It is also true that
for Java there were several platforms we needed to support out of the
box. Finally, there are performance issue with managed/non-managed
heap copies in Java that makes JNI unattractive (I don't know if this
applies to .NET too - although I did ask the question on this mailing
list some time ago without receiving any answer).

If your goal is to deliver a robust .NET client on a single platform
in a short timeframe going down a non-managed hybrid route doesn't to
me appear unreasonable.

>> I think it (fairly obviously) depends on the demands of our users (and
>> our perceptions of those demands). How many people want a .NET client
>> that doesn't work on any platform versus a WCF platform that works on
>> Windows?
> These goals shouldn't be contradictory.

Unless (perhaps) you add a time/cost goal into the mix. Although I
concede that I haven't done a detailed analysis on that personally.

> I think the above (building WCF on top of a lower level messaging API)
> should be our goal.  And further we should attempt to make that lower level
> API as independent as possible of particular AMQP versions (given the
> upcoming release - hopefully - of AMQP v1.0).
> My understanding is that Gordon, Rafi and others have been working hard on
> defining an abstract messaging API not bound to a particular version of AMQP
> but informed by AMQPs capabilities.  Further that the C++ and Python clients
> will be implementing this API so that each of these clients will implement a
> common API (obvious language differences aside).  I do not think it an
> unreasonable goal that we implement such a common low-level API across all
> our clients; and build things such as JMS and WCF on top of those (expecting
> that 90% of the user population in those languages would use the WCF or JMS
> api).  Having such a common low level API would also, one hopes, make it
> easier to transfer from a non-managed code underlying library to a managed
> code library for .net.

I agree that it would be very much worth exploring this. Once the
common API is implemented in C++ it should be no problem to expose
that directly in .NET :-)


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

View raw message