> 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
<marnie.mccorm...@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<rafa...@redhat.com
>>> >wrote:
>>>
>>>
>>>
>>>> Gordon Sim wrote:
>>>>
>>>>
>>>>
>>>>> On 05/10/2010 09:33 PM,tr...@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-subscr...@qpid.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
