On Mon, May 17, 2010 at 11:07 AM, Ted Ross <[email protected]> wrote: > 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.
While it is fine to leave it in qpid/cpp for the time being, I think long term we could perhaps move to something like the following. common (or core) brokers clients tools docs extras.. etc.. I don't know how feasible that is and how much work is involved. But I do know that there is some interest among the committers on this sorta re-org. So perhaps if there is a will, then there may be way :) > 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] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
