> -----Original Message----- > From: Rajith Attapattu [mailto:[email protected]] > > While I will leave it to the experts to comment about the > current approach, may I suggest that we make a prominent > notice in our download page that we have deprecated the 0-8 > and 0-10 .NET clients.
Good idea... A nice explanation that the .NET 0-8 and 0-10 clients will not be maintained and will not be in the Qpid 0.8 or future releases, along with a short explanation why and mention that 0.6 also includes WCF/.NET which will be included in future versions. > I know that several individuals have > put in some very good effort in the thankless task of > propping up these two code bases. But we have to be > pragmatic, and understand that we do not have the resources > to manage all these code bases. Right, and a plea for improvements/fixes got a little attention months ago and has since gone dead again, AFAIK. > I would actually go one step ahead and delete the 0-8 and > 0-10 client artefacts from our download page to prevent > people from using them any further. We should also probably > move those code bases out of the main tree into a "boneyard" dir. They could always be resurrected from svn if needed - I don't see a need for a "boneyard" area. -Steve > On Tue, May 11, 2010 at 3:36 PM, Gordon Sim <[email protected]> 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. > > > > --Gordon > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
