You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2010/05/11 21:36:27 UTC
[.net]: some debate please
On 05/10/2010 09:33 PM, tross@apache.org 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:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/11/2010 05:22 PM, Martin Ritchie wrote:
>
>
> -- Martin
>
> Sent from my iPhone
>
> On 11 May 2010, at 21:36, Rajith Attapattu <ra...@gmail.com> 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.
+1
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Martin Ritchie <ma...@gmail.com>.
--
Martin
Sent from my iPhone
On 11 May 2010, at 21:36, Rajith Attapattu <ra...@gmail.com> 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 <gs...@redhat.com> wrote:
>> On 05/10/2010 09:33 PM, tross@apache.org 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:dev-subscribe@qpid.apache.org
>>
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [.net]: some debate please
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Rajith Attapattu [mailto:rajith77@gmail.com]
>
> 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 <gs...@redhat.com> wrote:
> > On 05/10/2010 09:33 PM, tross@apache.org 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:dev-subscribe@qpid.apache.org
> >
> >
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Rajith Attapattu <ra...@gmail.com>.
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.
We should also probably move those code bases out of the main tree
into a "boneyard" dir.
Regards,
Rajith
On Tue, May 11, 2010 at 3:36 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 05/10/2010 09:33 PM, tross@apache.org 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:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, May 17, 2010 at 11:07 AM, Ted Ross <tr...@redhat.com> 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<ra...@redhat.com>wrote:
>>
>>
>>>
>>> Gordon Sim wrote:
>>>
>>>
>>>>
>>>> On 05/10/2010 09:33 PM,tross@apache.org 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:dev-subscribe@qpid.apache.org
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Gordon Sim <gs...@redhat.com>.
On 05/17/2010 04:07 PM, Ted Ross wrote:
> 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 agree on both these points[1].
Another aspect of the approach that appeals to me is that it extends the
same concepts that the c++ and python client are built on. This widens
the support base for those questions from .NET users that are not
specific to the .NET interface.
However it also seems sensible to at least consider in this context
whether the WCF functionality could - at some point in the future - be
built on top of this binding[2]. If the WCF stack remains entirely
independent the view that this removes a full-client implementation is
less compelling.
> 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 understand your point. However, it is another option that we are
potentially offering to .NET users meaning another option we may need to
maintain, document and answer questions for.
Thanks to all those participating in the debate both on this thread and
by Jira; this is exactly what I think we need!
--Gordon
[1] It is probably worth noting though that there are two separate
client implementations in the dotnet directory; one for 0-8 and one for
0-10. The new binding is at present only a valid replacement for the
latter as the c++ client does not support 0-8. Of course now that both
Qpid brokers support 0-10, that is not as big an issue.
[2] That may require some extension of the messaging API of course and
this is being explored on
https://issues.apache.org/jira/browse/QPID-2589 for those interested.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Marnie McCormack <ma...@googlemail.com>.
There are a host of inflight JIRAs for the Broker 0-10 work - but its not a
short list. Its top priority for me.
Marnie
On Tue, May 18, 2010 at 3:46 PM, Carl Trieloff <cc...@redhat.com>wrote:
> On 05/18/2010 10:37 AM, Marnie McCormack wrote:
>
>> I'll confess that I'm fairly uncomfortable with any other new .Net API,
>> especially since the current situation is that we have no client which can
>> interop across both brokers with all the other clients successfully (with
>> the Java Broker 0-10 code not yet complete/prod ready). I'd rather been
>> hoping we could get behind the new WCF client and build that out as the
>> replacement for the existing .Net components.
>>
>>
>
>
> I think the new WCF client is the direction. however it is bound directly
> to the old C++ 0-10 AMQP, and should at some point to updated to
> use the version independent API on the C++ side.
>
> My view is that it mainly about follow-through, and am glad to see Gordon
> and Cliff discussing the issues that need to be addressed to do that.
>
> The way to get the Java broker to talk WCF, without client proliferation
> should
> be to complete the 0-10 work on the Java broker.
>
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/18/2010 11:39 AM, Steve Huston wrote:
> Hi Jonathan,
>
>
>> > I want one WCF client that works with both brokers and interops with
>> > clients in all languages. I want only one. I want to avoid
>> > the confusion
>> > of having more than one, and I want to avoid putting effort into more
>> > than one
>> >
>> > I want the WCF client to use the new addressing scheme.
>> >
>> > Am I wanting the right things?
>>
When the Java Broker has 0-10 is complete, you will have this.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [.net]: some debate please
Posted by Steve Huston <sh...@riverace.com>.
Hi Jonathan,
> I want one WCF client that works with both brokers and interops with
> clients in all languages. I want only one. I want to avoid
> the confusion
> of having more than one, and I want to avoid putting effort into more
> than one
>
> I want the WCF client to use the new addressing scheme.
>
> Am I wanting the right things?
Those are good things to want, but that's not what you have now.
As far as interop, clients don't interop with languages; they interop
with AMQP peers. Saying WCF should interop with Python, for example,
isn't the goal - if WCF interops with a broker that your Python client
also interops with, you're good. If both clients can talk to the same
broker but can't exchange messages, that's a problem/bug.
The current WCF client doesn't interop with the pre-0-10 Java broker;
making ti do so would be a serious amount of work. The goal going
forward, I believe, is to focus on 0-10 and 1-0.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Jonathan Robie <jo...@redhat.com>.
I want one WCF client that works with both brokers and interops with
clients in all languages. I want only one. I want to avoid the confusion
of having more than one, and I want to avoid putting effort into more
than one
I want the WCF client to use the new addressing scheme.
Am I wanting the right things?
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/18/2010 10:37 AM, Marnie McCormack wrote:
> I'll confess that I'm fairly uncomfortable with any other new .Net API,
> especially since the current situation is that we have no client which can
> interop across both brokers with all the other clients successfully (with
> the Java Broker 0-10 code not yet complete/prod ready). I'd rather been
> hoping we could get behind the new WCF client and build that out as the
> replacement for the existing .Net components.
>
I think the new WCF client is the direction. however it is bound directly
to the old C++ 0-10 AMQP, and should at some point to updated to
use the version independent API on the C++ side.
My view is that it mainly about follow-through, and am glad to see Gordon
and Cliff discussing the issues that need to be addressed to do that.
The way to get the Java broker to talk WCF, without client proliferation
should
be to complete the 0-10 work on the Java broker.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/18/2010 10:49 AM, Marnie McCormack wrote:
> What client are you talking about here Carl ?
>
>
C++ and Python have been done. Some list discussion has happened on
Java. Ruby needs to be updated to Python style which missed 0.6, I believe
that is not a big job.
I understand that the update of Java client, to have API with ABI under JMS
that can also be used for JCA is a larger task.
WCF client needs to be updated to use new C++ API, discussion
between Cliff and Gordon happening on JIRA.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Marnie McCormack <ma...@googlemail.com>.
What client are you talking about here Carl ?
Marnie
On Tue, May 18, 2010 at 3:48 PM, Carl Trieloff <cc...@redhat.com>wrote:
> On 05/18/2010 10:37 AM, Marnie McCormack wrote:
>
>> Another key point is that if we're going to produce 'bindings' we need to
>> get much better at backwards compatibility on Qpid. We have existing C++
>> clients stranded on an old Qpid build as a result of some of our previous
>> decisions, along with C# users who won't be able to interop.
>>
>
>
> That is is whole point of all the debate on the new APIs, ABI and API
> compat. So we are getting there, big part done for 0.6. It is about
> follow-through and working the remaining client we are going to
> continue to maintain.
>
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/18/2010 10:37 AM, Marnie McCormack wrote:
> Another key point is that if we're going to produce 'bindings' we need to
> get much better at backwards compatibility on Qpid. We have existing C++
> clients stranded on an old Qpid build as a result of some of our previous
> decisions, along with C# users who won't be able to interop.
That is is whole point of all the debate on the new APIs, ABI and API
compat. So we are getting there, big part done for 0.6. It is about
follow-through and working the remaining client we are going to
continue to maintain.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Cliff Jansen <cl...@gmail.com>.
> Why would a user chose to use this binding instead
> of the WCF client - I guess thats the key question ?
If I understand the previous posts in this thread, the answer is that
people who are comfortable with WCF paradigms will use WCF, and people
who like to think a little closer to AMQP on the wire will use the new
messaging libraries. (See Rafael's post regarding JMS).
Presumably people who have already written something to the python and
C++ apis may find it more natural to port their work to .NET using
this new binding too.
On Tue, May 18, 2010 at 7:37 AM, Marnie McCormack
<ma...@googlemail.com> wrote:
> I'll confess that I'm fairly uncomfortable with any other new .Net API,
> especially since the current situation is that we have no client which can
> interop across both brokers with all the other clients successfully (with
> the Java Broker 0-10 code not yet complete/prod ready). I'd rather been
> hoping we could get behind the new WCF client and build that out as the
> replacement for the existing .Net components.
> Are there a set of .Net use cases that we're seeking to support - or even a
> set of minimal client use cases that this binding supports ? Does it support
> interop testing in CI ? Why would a user chose to use this binding instead
> of the WCF client - I guess thats the key question ?
>
> Are there docs out there for the bindings ?
>
> Another key point is that if we're going to produce 'bindings' we need to
> get much better at backwards compatibility on Qpid. We have existing C++
> clients stranded on an old Qpid build as a result of some of our previous
> decisions, along with C# users who won't be able to interop. I'd like us to
> start deprecating APIs in a consistent way going forward.
>
> Thanks,
> Marnie
>
>
> On Mon, May 17, 2010 at 4:07 PM, Ted Ross <tr...@redhat.com> 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.
>> 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<rafaels@redhat.com
>>> >wrote:
>>>
>>>
>>>
>>>> Gordon Sim wrote:
>>>>
>>>>
>>>>
>>>>> On 05/10/2010 09:33 PM,tross@apache.org 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:dev-subscribe@qpid.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Marnie McCormack <ma...@googlemail.com>.
I'll confess that I'm fairly uncomfortable with any other new .Net API,
especially since the current situation is that we have no client which can
interop across both brokers with all the other clients successfully (with
the Java Broker 0-10 code not yet complete/prod ready). I'd rather been
hoping we could get behind the new WCF client and build that out as the
replacement for the existing .Net components.
Are there a set of .Net use cases that we're seeking to support - or even a
set of minimal client use cases that this binding supports ? Does it support
interop testing in CI ? Why would a user chose to use this binding instead
of the WCF client - I guess thats the key question ?
Are there docs out there for the bindings ?
Another key point is that if we're going to produce 'bindings' we need to
get much better at backwards compatibility on Qpid. We have existing C++
clients stranded on an old Qpid build as a result of some of our previous
decisions, along with C# users who won't be able to interop. I'd like us to
start deprecating APIs in a consistent way going forward.
Thanks,
Marnie
On Mon, May 17, 2010 at 4:07 PM, Ted Ross <tr...@redhat.com> 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.
> 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<rafaels@redhat.com
>> >wrote:
>>
>>
>>
>>> Gordon Sim wrote:
>>>
>>>
>>>
>>>> On 05/10/2010 09:33 PM,tross@apache.org 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:dev-subscribe@qpid.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [.net]: some debate please
Posted by Ted Ross <tr...@redhat.com>.
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<ra...@redhat.com>wrote:
>
>
>> Gordon Sim wrote:
>>
>>
>>> On 05/10/2010 09:33 PM,tross@apache.org 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:dev-subscribe@qpid.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <ra...@redhat.com>wrote:
> Gordon Sim wrote:
>
>> On 05/10/2010 09:33 PM, tross@apache.org 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:dev-subscribe@qpid.apache.org
>
>
Re: [.net]: some debate please
Posted by Rafael Schloming <ra...@redhat.com>.
Gordon Sim wrote:
> On 05/10/2010 09:33 PM, tross@apache.org 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:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Rafael Schloming <ra...@redhat.com>.
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.
I think Java developers do need this as it addresses a number of use
cases that are not possible with JMS, e.g. explicit control over sync vs
async publish, unacked message windows, and prefetch, as well as better
support for non-blocking programming models. It's just lower priority
because JMS covers many of the common cases already. Also, it makes
sense to build it out and let it mature a bit in C++/Python before
trying to take it to other languages.
Really this API isn't a million miles away from JMS anyways, so an ideal
architecture would be JMS as a very thin layer on top of a Java version
of the API. This would allow people to use JMS for many things they
already know how to do there and then drop into the API for more
advanced scenarios.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Gordon Sim <gs...@redhat.com>.
On 05/12/2010 12:50 PM, Rafael Schloming wrote:
> Even if there isn't interest in using this API directly, I think there
> is huge benefit to having all the clients share a common architecture as
> much as possible. Since the purpose of the messaging API is really to
> expose all the features of AMQP while abstracting away the protocol
> details and not imposing a particular programming model on the
> application (e.g. not requiring applications to dedicate threads to
> handle blocking calls), it makes sense to me that each client would have
> a layer that corresponds to this even if it is not necessarily exposed
> directly.
I agree 100%!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Rafael Schloming <ra...@redhat.com>.
Gordon Sim wrote:
> 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.
Even if there isn't interest in using this API directly, I think there
is huge benefit to having all the clients share a common architecture as
much as possible. Since the purpose of the messaging API is really to
expose all the features of AMQP while abstracting away the protocol
details and not imposing a particular programming model on the
application (e.g. not requiring applications to dedicate threads to
handle blocking calls), it makes sense to me that each client would have
a layer that corresponds to this even if it is not necessarily exposed
directly.
Obviously this particularly makes sense for languages that can directly
use C/C++ code via swig or other means (which is actually pretty much
any language).
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Gordon Sim <gs...@redhat.com>.
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:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Cliff Jansen <cl...@gmail.com>.
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. The question
remains whether this new client intends to ignore distributed
transactions, including the new promotable transactions in AMQP 1.0.
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.
Carl Trieloff wrote:
> The current WCF uses the 0-10 API, I would suggest moving the WCF client
> to the updated C++ API. I believe this has been agreed to be done at some
> point before on the list which would then be consistent with this work
Actually the current WCF implementation uses the 0-10 C++ API where
convenient and bypasses it when necessary. The complete lack of
distributed transaction support in the updated C++ API means that even
more "behind the scenes" work will be required. But wherever
possible, the new messaging API would be used.
Regardless of recent events, the "Interop" layer of the WCF channel
was known to need rewriting for AMQP 1.0. I had hoped that the
rewrite would lead to a 0-10 and 1.0 friendly library which, surprise,
looks much like this messaging API plus qpid-config. But,
realistically, that would happen after many of the other TODO items in
the WCF Reame file were done.
Cliff
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/11/2010 05:59 PM, Steve Huston wrote:
>> > The current WCF uses the 0-10 API, I would suggest moving the
>> > WCF client to the updated C++ API. I believe this has been
>> > agreed to be done at some point before on the list which
>> > would then be consistent with this work
>>
> Ok, as long as somebody is committed to follow through with it - the
> existing WCF was a sizeable effort.
>
>
Ack, I don't think there is a rush, but it would be needed to be done at
least by the time AMQP 1.0 support is added.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [.net]: some debate please
Posted by Steve Huston <sh...@riverace.com>.
Hi Carl,
> -----Original Message-----
> From: Carl Trieloff [mailto:cctrieloff@redhat.com]
>
> On 05/11/2010 04:28 PM, Steve Huston wrote:
> >> -----Original Message-----
> >> From: Gordon Sim [mailto:gsim@redhat.com]
> >>
> >> On 05/10/2010 09:33 PM, tross@apache.org 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.
> >>
> > Right. This is nuts.
> >
> >
> >> 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.
> >>
> > I'm certainly not up to Cliff's level w/ .NET but I agree
> with Gordon
> > - this new approach is more elegant and probably more maintainable.
> > However, nobody has discussed:
> >
> > - What about the older .NET component(s)?
> >
>
> Deprecate them
I agree with this.
> > - How might this affect WCF?
> >
>
> The current WCF uses the 0-10 API, I would suggest moving the
> WCF client to the updated C++ API. I believe this has been
> agreed to be done at some point before on the list which
> would then be consistent with this work
Ok, as long as somebody is committed to follow through with it - the
existing WCF was a sizeable effort.
> > - Has anyone thought of how to package this?
> >
>
> I would package in the same way we package QMF binding to C++
Ok... Again, someone needs to follow through with this. I don't have
funding at this point to extend the installer for 0.8.
> > - Does it have any documentation or tests?
> >
>
> no idea..
Code without tests is a bad idea. I'd also say that new client/user code
must have documentation too.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/11/2010 04:28 PM, Steve Huston wrote:
>> -----Original Message-----
>> From: Gordon Sim [mailto:gsim@redhat.com]
>>
>> On 05/10/2010 09:33 PM, tross@apache.org 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.
>>
> Right. This is nuts.
>
>
>> 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.
>>
> I'm certainly not up to Cliff's level w/ .NET but I agree with Gordon -
> this new approach is more elegant and probably more maintainable.
> However, nobody has discussed:
>
> - What about the older .NET component(s)?
>
Deprecate them
> - How might this affect WCF?
>
The current WCF uses the 0-10 API, I would suggest moving the WCF client
to the updated C++ API. I believe this has been agreed to be done at some
point before on the list which would then be consistent with this work
> - Has anyone thought of how to package this?
>
I would package in the same way we package QMF binding to C++
> - Does it have any documentation or tests?
>
no idea..
my 2 cents.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [.net]: some debate please
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
>
> On 05/10/2010 09:33 PM, tross@apache.org 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.
Right. This is nuts.
> 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.
I'm certainly not up to Cliff's level w/ .NET but I agree with Gordon -
this new approach is more elegant and probably more maintainable.
However, nobody has discussed:
- What about the older .NET component(s)?
- How might this affect WCF?
- Has anyone thought of how to package this?
- Does it have any documentation or tests?
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org