You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rafael Schloming <ra...@redhat.com> on 2009/11/30 17:56:30 UTC
dotnet/wcf roadmap (was Re: 10000 msgs limit per session)
Carl Trieloff wrote:
> Robert Godfrey wrote:
>>
>>
>> 2009/11/30 Carl Trieloff <cctrieloff@redhat.com
>> <ma...@redhat.com>>
>>
>> Aidan Skinner wrote:
>>
>> On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff
>> <cctrieloff@redhat.com <ma...@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-subscribe@qpid.apache.org
Re: dotnet/wcf roadmap (was Re: 10000 msgs limit per session)
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Nov 30, 2009 at 11:56 AM, Rafael Schloming <ra...@redhat.com> wrote:
> Carl Trieloff wrote:
>>
>> Robert Godfrey wrote:
>>>
>>>
>>> 2009/11/30 Carl Trieloff <cctrieloff@redhat.com
>>> <ma...@redhat.com>>
>>>
>>> Aidan Skinner wrote:
>>>
>>> On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff
>>> <cctrieloff@redhat.com <ma...@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.
I think we probably need to have a discussion about the strategy
around supporting our .NET users.
I don't think we do have a clear concise document that explains what
our position as project is w.r.t to .NET support.
One of the goals of Qpid is to have a consistent set of API's across
all languages.
However for Java we have JMS as the API, as that is the standard Java API.
We may in the future provide a non JMS API similar to the new
python/c++ APIs that are being worked out.
WCF seems to be the standard communications framework in the windows
.NET 3.0 environment.
And I believe what Cliff has done is to provide an AMQP adapter for WCF.
I think from a .NET on windows developers perspective, this piece
seems as valuable as JMS for a Java user.
However as many pointed out this will not work outside of a windows environment.
So in that sense the WCF adapter is not a replacement for the existing
.NET client.
If I am not mistaken, the existing .NET client can be run on windows
as well as mono.
However this client suffers from neglect as it really doesn't have an
owner/maintainer.
Perhaps it's worthwhile answering the following questions.
1. Now as a project do we want to support both a WCF adapter and .NET client?
2. If so do we have enough resources and know how to maintain both ?
3. If we don't can we discontinue until we get enough resources. IMO
it's best to not support at all rather than having something that's
half baked and buggy due to no maintenance.
4. If we decide to have .NET client that runs on windows and mono then
how should the API look like? I'd argue it should be similar to the
current effort undertaken in python and C++.
Regards,
Rajith
> --Rafael
>
>
> ---------------------------------------------------------------------
> 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