Robert Greig wrote:
2009/12/1 Robert Godfrey <rob.j.godf...@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-subscr...@qpid.apache.org
