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
>
>
