I commented on the Jira but I'll jump in on this thread in case folks
are not reading the Jira comments.
The contribution in question is a thin .Net binding for the new C++
messaging API. This is why it was placed in the qpid/cpp/bindings area
and not in the qpid/{dotnet,wcf} areas or in its own new
top-level-directory. This is where several other-language bindings
currently reside. I think we should be developing bindings for the API
in as many languages as we can (Python, Ruby, PHP, Perl, Java, etc.).
This binding does not add any "messaging" value to the API. If new
features or new behavior are desired, the underlying C++ API should be
enhanced and the language bindings updated to reflect those enhancements.
The contribution simply allows .NET programs in C#, VB, Powershell,
Excel, etc. to access the Qpid C++ messaging API. It is not in the same
category as the qpid/wcf code which adds substantial value over and
above basic messaging.
The advantage of the thin-binding approach over the existing dotnet
full-client-implementation-in-C# is that it removes the need to support
yet another full-client implementation. The dotnet code is currently
unmaintained, we need a better way to support .NET users.
I apologize for committing this patch to trunk without sufficient
debate. I considered this to be more of an added feature to the C++
client and less of a whole-new-direction for .NET. I see that I was
wrong and will, of course, abide by what the community decides is best.
-Ted
On 05/14/2010 04:38 PM, Marnie McCormack wrote:
I don't have a strong view on the 'correct' approach since I'm not familiar
with the .Net components.
However, I agree wholeheartedly with Rafi's comments about dropping this in
without a discussion beforehand (and apologies if I missed one?). If I was
an existing .Net contributer I'd be pretty hacked off I think !
What should we do now while the discussion on this takes place ?
Marnie
On Wed, May 12, 2010 at 11:59 AM, Rafael Schloming<[email protected]>wrote:
Gordon Sim wrote:
On 05/10/2010 09:33 PM,[email protected] wrote:
Author: tross
Date: Mon May 10 20:33:19 2010
New Revision: 942892
URL:http://svn.apache.org/viewvc?rev=942892&view=rev
Log:
QPID-2589 - Applied patch from Chuck Rolke.
This commit adds a new component and yet another approach for .net,
specifically a .net wrapper around the c++ messaging API.
We also have a wcf client (this also uses some c++ code, but uses the 0-10
specific API plus some direct use of the internals of the client), and two
different pure c# clients for 0-8 and 0-10 respectively.
Four different options each with its own codebase isn't sensible. We can't
maintain them all and it is confusing for users.
While aspects of this latest approach certainly appeal to me personally
(the messaging API is better for a number of reasons than the older API and
wrapping that also keeps the clients more aligned conceptually), I think it
deserves a bit more debate. Specifically we have to explicitly decide as a
community whether this new approach is a path we should pursue. I'm keen to
hear the thoughts of Cliff, Aidan and other .net aficionados.
While I prefer depending on the new C++ messaging API to depending on the
old one, I don't think either one is really the correct choice. I think the
WCF client should actually depend on a C# interface to the message API, thus
giving something that is more reasonable to use directly from C#, while
being able to be back-ended by either the C++ implementation of the
messaging API or by a pure C# implementation if one is so inclined to write
one.
On purely procedural note, it is IMHO *very* bad form to drop such a patch
into the repo without some list discussion prior. I'm particularly
uncomfortable that this was committed by someone who (as far as I'm aware)
is not a regular WCF committer, nor intends to become one.
This has been the general approach in this area since the first dotnet
effort ages ago. It's no wonder there are 4 completely different approaches
half of which are rotting. Cleaning out the rot is only half the problem
here, we *really* have to stop doing stuff like this or we'll keep on making
more rot.
IMHO this patch should be backed out until some discussion has happened and
its clear that those responsible for maintaining WCF going forward are
comfortable with the approach.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:http://qpid.apache.org
Use/Interact:mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
