Gordon Sim wrote:
On 05/12/2010 11:21 AM, Cliff Jansen wrote:
Perhaps it would be useful for somebody to assist this debate by
introducing the messaging API in the .NET context and addressing why,
for example, .NET programmers need this API, but Java programmers
don't. Or why a developer who might be inclined to use WCF should use
this messaging API instead.
Looking at the initial code drop, I have a very hard time imagining a
.NET programmer who might feel remotely comfortable using it. This is
not a comment on the quality or functionality of the module, just on
the utter disregard for basic .NET conventions of the C++ API as
transposed to .NET, i.e. the surface area of the library. I don't
think it would take a lot of work to address this.
I think a natural .NET interface is essential ans I expect on that point
we will all agree.
Whether there would be any interest in using an API like that available
in c++/python directly instead of just using WCF is an important
question. I don't have an answer for that at present.
Even if there isn't interest in using this API directly, I think there
is huge benefit to having all the clients share a common architecture as
much as possible. Since the purpose of the messaging API is really to
expose all the features of AMQP while abstracting away the protocol
details and not imposing a particular programming model on the
application (e.g. not requiring applications to dedicate threads to
handle blocking calls), it makes sense to me that each client would have
a layer that corresponds to this even if it is not necessarily exposed
directly.
Obviously this particularly makes sense for languages that can directly
use C/C++ code via swig or other means (which is actually pretty much
any language).
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
