--
Martin
Sent from my iPhone
On 11 May 2010, at 21:36, Rajith Attapattu <[email protected]> wrote:
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.
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.
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.
I'd leave the artefacts up for the previosly releases we just should
ship them again as that implies that have been maintained. I've said
this before but I think our approach to always releasing every
component at once is wrong. If no work has been done to maintain or
test components then they shouldn't get a new release.
We should also probably move those code bases out of the main tree
into a "boneyard" dir.
This seem like a good idea we have discussed this notion before. We
also talked about an experimental directory for incomming work, such
as this new client, so we can evaluate and see there is some level of
commitment to maintain it. To that end I've added an experimental dir
to the java broker-plugins, but more on that when I have a full
keyboard.
Regards,
Rajith
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]
