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.
The question
remains whether this new client intends to ignore distributed
transactions, including the new promotable transactions in AMQP 1.0.
We certainly do want the c++ messaging API to be extended to allow
distributed transaction support to be added. (I'd also be keen on
exploring any optimisations on handling body content).
But compared to the existing dotnet client, from a practical point of
view, a module whose heavy lifting is largely done in the C++ space
will automatically benefit from bug fixes to that code base. This
beats the current dotnet mechanism of running a code translator
against a Java snapshot every other year.
I think the approach to implementing whatever interface(s) is(are)
exposed to .NET users is also important to us as a community. Re-using
another implementation to reduce the amount of specific code clearly has
the potential to reduce the maintenance burden. It may of course have
some downsides as well.
The key I think is to discuss these points openly and try to reach some
agreement on approach. We need to co-ordinate our efforts and we can
only do so by sharing our ideas.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
