qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: 10000 msgs limit per session
Date Wed, 02 Dec 2009 00:39:00 GMT
Robert Greig wrote:
> 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.

FWIW, I never intended to suggest we should go out of our way to support 
mono specifically. I just meant that we should probably target dotnet as 
a platform rather than windows. If the code didn't work on mono due to a 
mono bug, I wouldn't really be bothered. The fact that it can't work on 
mono because of the way its written is a different issue.

> 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 don't think anyone has said that its an unreasonable approach if you 
only care about supporting windows. The question is whether or not that 
goal meshes particularly well with the goals of the qpid project.

>>> 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 :-)

I hesitate to speak for Gordon, but since he's on vacation I'll go out 
on a limb and say that while there is still more work to do, the C++ API 
should be implemented enough to support the stuff that the WCF impl is 
doing and a fair bit more AFAICT.

--Rafael


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


Mime
View raw message