Carl Trieloff wrote:
Robert Godfrey wrote:
2009/11/30 Carl Trieloff <cctriel...@redhat.com
<mailto:cctriel...@redhat.com>>
Aidan Skinner wrote:
On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff
<cctriel...@redhat.com <mailto:cctriel...@redhat.com>> wrote:
The old 0-10 version that is pure .NET (0.5) or the
updated version that
Cliff has been working extensively on (coming in 0.6 from
trunk)?
Sorry if this is confusing, we should deprecate the old
one from the source
tree...
I'm really not sure about deprecating the 0-10 one. It's had some
testing and maintanance, and the new one lacks a few important
features such as not being portable to other .Net
implementations.
We should track it somehow to know when the new client supersedes
the current
one in completeness.
Carl.
I'm not sure how useful a metric this is as I would argue that none of
our .net clients have been completely production ready (as Rafi
pointed out earlier). Furthermore my understanding was that the
client currently being developed cannot easily be ported to run on
.net platforms other than Windows (i.e. it will no be available to
users of Mono) and therefore cannot completely supersede the existing
C# based client in that way .
I'm very supportive of the efforts to make available a WCF client for
Qpid (and more generally, I hope, for AMQP) however I think we need to
look a little more carefully about how we are going to go forward
supporting .net application programmers and - something that tends to
get a little lost - how we enable .net programmers to interoperate
seamlessly with clients using other APIs (for example JMS <-> .net/WCF)..
We collectively have a better understanding of how we expect .net
users (across all platforms) to interact with other AMQP clients and
the messaging patterns they use. until we have that I don't think we
can say that any of our .net clients is the way forward.
Underling my question is, is our goal that the new client will do
everything the old one does and replace it ?
My understanding was yes... sounds like a thread of discussion is needed.
I think there has understandably been an implicit assumption that we
want fewer than three separate incompatible, incomplete, and partially
overlapping implementations in the .net/WCF area, however there hasn't
really been any discussion about how to achieve that.
I'm not a WCF expert, but reading the wikipedia page makes me think that
WCF isn't quite the same thing as a messaging API, and I'm concerned
that having only a WCF implementation will not afford C# users the same
capabilities present in our other clients. My impression is that WCF is
actually more akin to QMF than to our messaging APIs, i.e. a framework
built on top of messaging rather than a messaging API in and of itself.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
