You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Marnie McCormack <ma...@googlemail.com> on 2009/01/08 10:53:27 UTC
Qpid .NET Strategy - Interested ?
All,
We are currently in a somewhat interesting situation wrt to .NET clients in
Qpid. I thought it might be helpful to get together the group of interested
parties to agree the best way forward for the existing clients, and also to
do some retrospective/forward looking requirements capture to help to
clarify our aims.
Can you reply if you'd be interested in attending a conference call to
discuss this please ? We will (of course) post the notes/actions/decisions
back to the list.
I'll endeavour to make the session as widely attend-able as possible.
Thanks & Regards,
Marnie
Re: Qpid .NET Strategy - Interested ?
Posted by Carl Trieloff <cc...@redhat.com>.
I know the Microsoft guys had had some ideas in this area also, Anandeep
do you want to chip in
with your thoughts? It would most likely be useful to add that to the
discussion.
regards,
Carl.
Gordon Sim wrote:
> Marnie McCormack wrote:
>> We have (to the best of my knowledge) no requriements spec for either
>> implementation, functional or non-functional.
>
> I think the basic requirement for a client is to allow a user to
> exploit the features of the protocol version in question.
>
> There may be other relevant APIs for particular languages, so e.g. for
> .Net WCF support might be an additional requirement. Of course there
> may then be more detailed requirements about the mapping from the API
> in question to AMQP.
>
>> So, I think we need to discuss how we're taking the .NET client forward
>> including:
>> - identify what the key differences between the client
>> implementations are
>> (beyond protocol versions etc)
>> - discuss migration paths for existing users
>> - version negotiation/future proofing ?
>
> I think the supported APIs are particularly relevant for these last
> two items (API differences are probably a big part of the first item
> also).
>
>> - testing, including the interop test runner integration
>
> I've been meaning to comment on this more generally.
>
> The examples that we have in python, c++ and JMS have been another way
> of testing interoperability between clients. I think they currently
> probably have at least as good coverage as the defined interop tests
> (though at present the python examples are 0-10 only).
>
> There are scripts for automated runs of the clients against each other
> in all combinations. (In fact, we run the python and c++ ones as part
> of the c++ 'make check').
>
> I was very much in support of the interop framework approach, but with
> the benefit of hindsight, the simpler approach followed in verifying
> the examples has I think ended up being more successful.
>
> We are always going to want to have examples to show users how to do
> various things; we need to run those regularly in all combinations to
> ensure they all work. Using that same approach for testing interop
> between clients feels like worthwhile conservation of energy.
>
> Thoughts?
>
>> - active commiters/contributers for the .NET
>> - known use cases we should address
>
> This might be a good question to ask on the user list.
>
>> At the end, I'd like us to have a strategy we are all happy with and
>> a clear
>> development roadmap for .NET users.
>>
>> Ideally this session would also allow some of our new windows
>> developers to
>> get involved and to influence what we're doing with the client.
>
> I think it would be worth opening up some specific email debates on
> this list and/or the user list. That doesn't prevent any telephone
> conversations, but I think an email thread will have wider
> participation and will consequently be a useful source of input.
>
>> Hope this sheds some light,
>
> Yes, very helpful. Thank you!
Re: Qpid .NET Strategy - Interested ?
Posted by Gordon Sim <gs...@redhat.com>.
Aidan Skinner wrote:
> On Thu, Jan 8, 2009 at 11:25 AM, Gordon Sim <gs...@redhat.com> wrote:
>
>> Marnie McCormack wrote:
>>> We have (to the best of my knowledge) no requriements spec for either
>>> implementation, functional or non-functional.
>> I think the basic requirement for a client is to allow a user to exploit the
>> features of the protocol version in question.
>
> I think that's certainly important but I think having a stable,
> idiomatic API is perhaps more important. I think this is particularly
> important until AMQP stabalises, given the changes between 0-8/0-9,
> 0-10 and the proposed 1-0 drafts.
>
> It would be very difficult to write an application which talked all
> three, and often all you want is "put message on queue A, get message
> from queue B".
Yes, I agree that a high level interface to the basic operations that
remain unchangeable is very valuable. My point wasn't meant to imply
that a client must expose the protocol in all its gory details, but that
the basic purpose of any client code is simply to exploit some feature
of AMQP (e.g. sending a message).
> Having access to the underlying protocol is certainly necessary for
> some applications, but I think it's something we should be
> discouraging generally and providing means to avoid where possible.
Agreed.
>> There may be other relevant APIs for particular languages, so e.g. for .Net
>> WCF support might be an additional requirement. Of course there may then be
>> more detailed requirements about the mapping from the API in question to
>> AMQP.
>
> I think System.Messaging is probably more relevant to .Net, this is
> the route that Mono has gone down with ActiveMQ and RabbitMQ:
> http://www.mono-project.com/SystemMessaging (there was also an attempt
> to implement it on top of our 0-8 client but that didn't work out).
I'm pretty ignorant of both WCF and System.Messaging; my comment was
really just an example of using an existing and applicable API where one
exists. This seems like another good point to discuss on the user list.
>> I was very much in support of the interop framework approach, but with the
>> benefit of hindsight, the simpler approach followed in verifying the
>> examples has I think ended up being more successful.
>>
>> We are always going to want to have examples to show users how to do various
>> things; we need to run those regularly in all combinations to ensure they
>> all work. Using that same approach for testing interop between clients feels
>> like worthwhile conservation of energy.
>>
>> Thoughts?
>
> The framework is a good idea, but is somewhat poorly implemented. I'd
> be quite interested in a generic system which took test cases in xml
> and ran them using the implementation of choice.
While I see the attraction of this, I'm not convinced it would be
successful in practice. It ends up being the design of a new xml based
messaging language and I foresee new tests continually coming up against
limitations in that language.
Automated runs of example programs has the benefit of allowing the
example to do anything that can be expressed in the client language with
the API offered.
> I think OpenAMQ may
> have something similar. At the moment adding a test case is a lot of
> work and ends up being duplicated across the different
> implementations.
Yes, and since some effort is expended on examples anyway, and those can
be used to verify interop as well, duplicated work is even less attractive.
> This is a more general discussion though, we should
> probably start a seperate thread.
Agreed.
Re: Qpid .NET Strategy - Interested ?
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Greig wrote:
> 2009/1/8 Aidan Skinner <ai...@apache.org>:
>
>
>> I think System.Messaging is probably more relevant to .Net, this is
>> the route that Mono has gone down with ActiveMQ and RabbitMQ:
>> http://www.mono-project.com/SystemMessaging (there was also an attempt
>> to implement it on top of our 0-8 client but that didn't work out).
>>
>
> My experience has been that WCF is key for new .NET development. I
> have recently worked on a project that used WCF with IBM MQ, along
> with CXF (this was using SOAP over messaging).
>
> That's not to say System.Messaging is not desirable, but the WCF for
> IBM MQ saved us a lot of time and effort.
>
> RG
>
Rob,
How close is the WCF layer we have in 0-10 .NET client to what you would
use in
such a use-case?
Carl.
Re: Qpid .NET Strategy - Interested ?
Posted by William Henry <wh...@redhat.com>.
+1 re WCF. WCF makes it much easier.
----- "Robert Greig" <ro...@gmail.com> wrote:
> 2009/1/8 Aidan Skinner <ai...@apache.org>:
>
> > I think System.Messaging is probably more relevant to .Net, this is
> > the route that Mono has gone down with ActiveMQ and RabbitMQ:
> > http://www.mono-project.com/SystemMessaging (there was also an
> attempt
> > to implement it on top of our 0-8 client but that didn't work out).
>
> My experience has been that WCF is key for new .NET development. I
> have recently worked on a project that used WCF with IBM MQ, along
> with CXF (this was using SOAP over messaging).
>
> That's not to say System.Messaging is not desirable, but the WCF for
> IBM MQ saved us a lot of time and effort.
>
> RG
Re: Qpid .NET Strategy - Interested ?
Posted by Carl Trieloff <cc...@redhat.com>.
I also want to be on
Marnie McCormack wrote:
> Thanks for all your replies on this thread.
>
> I'll schedule a call to get the initial discussion going.
>
> To that end, if anyone is based outside the UK, USA and Canada - and would
> like to attend, please let me know ?
>
> Otherwise, I'll try to accomodate those three timezones in the call
> planning.
>
> Thanks & Regards,
> Marnie
>
> On Fri, Jan 9, 2009 at 2:27 AM, Cliff Jansen (Interop Systems Inc) <
> v-cljans@microsoft.com> wrote:
>
>
>>> My impression has been that WCF is purely an RPC abstraction. Does it
>>> offer traditional messaging semantics as well?
>>>
>> Yes. For example, the Microsoft "StockTrader" sample application uses WCF
>> and MSMQ to provide the same functionality as IBM's "Trade" sample
>> application using JMS over IBM's Service Integration Bus - i.e. distributed
>> transactions over durable message queues.
>>
>> A properly coded WCF application can switch its underlying messaging
>> channel stack just by changing a configuration file, in the same way a Java
>> application can switch JMS providers without code changes.
>>
>> Cliff
>>
>> -----Original Message-----
>> From: Aidan Skinner [mailto:aidan.skinner@gmail.com]
>> Sent: Thursday, January 08, 2009 2:35 PM
>> To: dev@qpid.apache.org
>> Subject: Re: Qpid .NET Strategy - Interested ?
>>
>> On Thu, Jan 8, 2009 at 8:39 PM, Robert Greig <ro...@gmail.com>
>> wrote:
>>
>>
>>> 2009/1/8 Aidan Skinner <ai...@apache.org>:
>>>
>>>
>>>> I think System.Messaging is probably more relevant to .Net, this is
>>>> the route that Mono has gone down with ActiveMQ and RabbitMQ:
>>>> http://www.mono-project.com/SystemMessaging (there was also an attempt
>>>> to implement it on top of our 0-8 client but that didn't work out).
>>>>
>>> My experience has been that WCF is key for new .NET development. I
>>> have recently worked on a project that used WCF with IBM MQ, along
>>> with CXF (this was using SOAP over messaging).
>>>
>>> That's not to say System.Messaging is not desirable, but the WCF for
>>> IBM MQ saved us a lot of time and effort.
>>>
>> My impression has been that WCF is purely an RPC abstraction. Does it
>> offer traditional messaging semantics as well?
>>
>> Having said that, I've never done any async messaging with .Net, just
>> synchronous SOAP-over-HTTP. I also guess it's arguable that RPC
>> semantics are what most people actually want with messaging, even if
>> they haven't quite figured it out. ;)
>>
>> - Aidan
>>
>> --
>> Apache Qpid - World Domination through Advanced Message Queueing
>> http://qpid.apache.org
>>
>>
>>
>
>
Re: Qpid .NET Strategy - Interested ?
Posted by Marnie McCormack <ma...@googlemail.com>.
Thanks for all your replies on this thread.
I'll schedule a call to get the initial discussion going.
To that end, if anyone is based outside the UK, USA and Canada - and would
like to attend, please let me know ?
Otherwise, I'll try to accomodate those three timezones in the call
planning.
Thanks & Regards,
Marnie
On Fri, Jan 9, 2009 at 2:27 AM, Cliff Jansen (Interop Systems Inc) <
v-cljans@microsoft.com> wrote:
> > My impression has been that WCF is purely an RPC abstraction. Does it
> > offer traditional messaging semantics as well?
>
> Yes. For example, the Microsoft "StockTrader" sample application uses WCF
> and MSMQ to provide the same functionality as IBM's "Trade" sample
> application using JMS over IBM's Service Integration Bus - i.e. distributed
> transactions over durable message queues.
>
> A properly coded WCF application can switch its underlying messaging
> channel stack just by changing a configuration file, in the same way a Java
> application can switch JMS providers without code changes.
>
> Cliff
>
> -----Original Message-----
> From: Aidan Skinner [mailto:aidan.skinner@gmail.com]
> Sent: Thursday, January 08, 2009 2:35 PM
> To: dev@qpid.apache.org
> Subject: Re: Qpid .NET Strategy - Interested ?
>
> On Thu, Jan 8, 2009 at 8:39 PM, Robert Greig <ro...@gmail.com>
> wrote:
>
> > 2009/1/8 Aidan Skinner <ai...@apache.org>:
> >
> >> I think System.Messaging is probably more relevant to .Net, this is
> >> the route that Mono has gone down with ActiveMQ and RabbitMQ:
> >> http://www.mono-project.com/SystemMessaging (there was also an attempt
> >> to implement it on top of our 0-8 client but that didn't work out).
> >
> > My experience has been that WCF is key for new .NET development. I
> > have recently worked on a project that used WCF with IBM MQ, along
> > with CXF (this was using SOAP over messaging).
> >
> > That's not to say System.Messaging is not desirable, but the WCF for
> > IBM MQ saved us a lot of time and effort.
>
> My impression has been that WCF is purely an RPC abstraction. Does it
> offer traditional messaging semantics as well?
>
> Having said that, I've never done any async messaging with .Net, just
> synchronous SOAP-over-HTTP. I also guess it's arguable that RPC
> semantics are what most people actually want with messaging, even if
> they haven't quite figured it out. ;)
>
> - Aidan
>
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://qpid.apache.org
>
>
Re: Qpid .NET Strategy - Interested ?
Posted by Robert Greig <ro...@gmail.com>.
2009/1/14 Aidan Skinner <ai...@gmail.com>:
> On Wed, Jan 14, 2009 at 4:02 PM, William Henry <wh...@redhat.com> wrote:
>
>> Websphere JMS adapter etc. Of course the great thing about AMQP is that it is an open standard protocol for on the wire. So if
>> JMS vendors start supporting that then the WCF AMQP adapter will work with all of them ;-)
>
> So I should be able to take the Qpid JMS client, put some text into a
> message and retrieve it from the Qpid WCF client and vice versa?
This is certainly possible with other products. For example, in my day
job we have a heterogeneous environment that uses IBM MQ. We use WCF,
CXF and JMS to allow SOAP over JMS between .NET components and
Mule-hosted Java components.
That could be an interesting example/testcase for qpid.
RG
Re: Qpid .NET Strategy - Interested ?
Posted by Aidan Skinner <ai...@gmail.com>.
On Wed, Jan 14, 2009 at 4:02 PM, William Henry <wh...@redhat.com> wrote:
> Websphere JMS adapter etc. Of course the great thing about AMQP is that it is an open standard protocol for on the wire. So if
> JMS vendors start supporting that then the WCF AMQP adapter will work with all of them ;-)
So I should be able to take the Qpid JMS client, put some text into a
message and retrieve it from the Qpid WCF client and vice versa?
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Re: Qpid .NET Strategy - Interested ?
Posted by William Henry <wh...@redhat.com>.
Hi Aidan,
----- "Aidan Skinner" <ai...@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 2:27 AM, Cliff Jansen (Interop Systems Inc)
> <v-...@microsoft.com> wrote:
> >> My impression has been that WCF is purely an RPC abstraction. Does
> it
> >> offer traditional messaging semantics as well?
> >
> > Yes. For example, the Microsoft "StockTrader" sample application
> uses WCF and MSMQ to provide the same functionality as IBM's "Trade"
> sample application using JMS over IBM's Service Integration Bus - i.e.
> distributed transactions over durable message queues.
>
> Interesting. Is it possible to do heterogeneous messaging with this?
> Could I have a JMS client on one end and a WCF client on the other
> without jumping through a lot of hoops?
I it is my understanding that if you have the correct WCF adapters then you can do this. IONA's ART technology was similar to this. the idea is that you can provide a uniform interface to the application programmer in .NET but that various plugins can be configured to provide different protocols or transports for integration with non-.NET platforms. So there could be an IIOP adapter or an FTP adapter or etc. In our case you can have an AMQP adapter. NO the issue with JMS is that JMS doesn't have a standard protocol on the wire and so you would have to have a specific JMS implementation adapter, e.g. an SonicMQ adapter, or a Websphere JMS adapter etc. Of course the great thing about AMQP is that it is an open standard protocol for on the wire. So if JMS vendors start supporting that then the WCF AMQP adapter will work with all of them ;-)
Best,
William
>
> - Aidan
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://qpid.apache.org
Re: Qpid .NET Strategy - Interested ?
Posted by Aidan Skinner <ai...@gmail.com>.
On Fri, Jan 9, 2009 at 2:27 AM, Cliff Jansen (Interop Systems Inc)
<v-...@microsoft.com> wrote:
>> My impression has been that WCF is purely an RPC abstraction. Does it
>> offer traditional messaging semantics as well?
>
> Yes. For example, the Microsoft "StockTrader" sample application uses WCF and MSMQ to provide the same functionality as IBM's "Trade" sample application using JMS over IBM's Service Integration Bus - i.e. distributed transactions over durable message queues.
Interesting. Is it possible to do heterogeneous messaging with this?
Could I have a JMS client on one end and a WCF client on the other
without jumping through a lot of hoops?
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
RE: Qpid .NET Strategy - Interested ?
Posted by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>.
> My impression has been that WCF is purely an RPC abstraction. Does it
> offer traditional messaging semantics as well?
Yes. For example, the Microsoft "StockTrader" sample application uses WCF and MSMQ to provide the same functionality as IBM's "Trade" sample application using JMS over IBM's Service Integration Bus - i.e. distributed transactions over durable message queues.
A properly coded WCF application can switch its underlying messaging channel stack just by changing a configuration file, in the same way a Java application can switch JMS providers without code changes.
Cliff
-----Original Message-----
From: Aidan Skinner [mailto:aidan.skinner@gmail.com]
Sent: Thursday, January 08, 2009 2:35 PM
To: dev@qpid.apache.org
Subject: Re: Qpid .NET Strategy - Interested ?
On Thu, Jan 8, 2009 at 8:39 PM, Robert Greig <ro...@gmail.com> wrote:
> 2009/1/8 Aidan Skinner <ai...@apache.org>:
>
>> I think System.Messaging is probably more relevant to .Net, this is
>> the route that Mono has gone down with ActiveMQ and RabbitMQ:
>> http://www.mono-project.com/SystemMessaging (there was also an attempt
>> to implement it on top of our 0-8 client but that didn't work out).
>
> My experience has been that WCF is key for new .NET development. I
> have recently worked on a project that used WCF with IBM MQ, along
> with CXF (this was using SOAP over messaging).
>
> That's not to say System.Messaging is not desirable, but the WCF for
> IBM MQ saved us a lot of time and effort.
My impression has been that WCF is purely an RPC abstraction. Does it
offer traditional messaging semantics as well?
Having said that, I've never done any async messaging with .Net, just
synchronous SOAP-over-HTTP. I also guess it's arguable that RPC
semantics are what most people actually want with messaging, even if
they haven't quite figured it out. ;)
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Re: Qpid .NET Strategy - Interested ?
Posted by Aidan Skinner <ai...@gmail.com>.
On Thu, Jan 8, 2009 at 8:39 PM, Robert Greig <ro...@gmail.com> wrote:
> 2009/1/8 Aidan Skinner <ai...@apache.org>:
>
>> I think System.Messaging is probably more relevant to .Net, this is
>> the route that Mono has gone down with ActiveMQ and RabbitMQ:
>> http://www.mono-project.com/SystemMessaging (there was also an attempt
>> to implement it on top of our 0-8 client but that didn't work out).
>
> My experience has been that WCF is key for new .NET development. I
> have recently worked on a project that used WCF with IBM MQ, along
> with CXF (this was using SOAP over messaging).
>
> That's not to say System.Messaging is not desirable, but the WCF for
> IBM MQ saved us a lot of time and effort.
My impression has been that WCF is purely an RPC abstraction. Does it
offer traditional messaging semantics as well?
Having said that, I've never done any async messaging with .Net, just
synchronous SOAP-over-HTTP. I also guess it's arguable that RPC
semantics are what most people actually want with messaging, even if
they haven't quite figured it out. ;)
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Re: Qpid .NET Strategy - Interested ?
Posted by Robert Greig <ro...@gmail.com>.
2009/1/8 Aidan Skinner <ai...@apache.org>:
> I think System.Messaging is probably more relevant to .Net, this is
> the route that Mono has gone down with ActiveMQ and RabbitMQ:
> http://www.mono-project.com/SystemMessaging (there was also an attempt
> to implement it on top of our 0-8 client but that didn't work out).
My experience has been that WCF is key for new .NET development. I
have recently worked on a project that used WCF with IBM MQ, along
with CXF (this was using SOAP over messaging).
That's not to say System.Messaging is not desirable, but the WCF for
IBM MQ saved us a lot of time and effort.
RG
Re: Qpid .NET Strategy - Interested ?
Posted by Aidan Skinner <ai...@apache.org>.
On Thu, Jan 8, 2009 at 11:25 AM, Gordon Sim <gs...@redhat.com> wrote:
> Marnie McCormack wrote:
>>
>> We have (to the best of my knowledge) no requriements spec for either
>> implementation, functional or non-functional.
>
> I think the basic requirement for a client is to allow a user to exploit the
> features of the protocol version in question.
I think that's certainly important but I think having a stable,
idiomatic API is perhaps more important. I think this is particularly
important until AMQP stabalises, given the changes between 0-8/0-9,
0-10 and the proposed 1-0 drafts.
It would be very difficult to write an application which talked all
three, and often all you want is "put message on queue A, get message
from queue B".
Having access to the underlying protocol is certainly necessary for
some applications, but I think it's something we should be
discouraging generally and providing means to avoid where possible.
> There may be other relevant APIs for particular languages, so e.g. for .Net
> WCF support might be an additional requirement. Of course there may then be
> more detailed requirements about the mapping from the API in question to
> AMQP.
I think System.Messaging is probably more relevant to .Net, this is
the route that Mono has gone down with ActiveMQ and RabbitMQ:
http://www.mono-project.com/SystemMessaging (there was also an attempt
to implement it on top of our 0-8 client but that didn't work out).
> I was very much in support of the interop framework approach, but with the
> benefit of hindsight, the simpler approach followed in verifying the
> examples has I think ended up being more successful.
>
> We are always going to want to have examples to show users how to do various
> things; we need to run those regularly in all combinations to ensure they
> all work. Using that same approach for testing interop between clients feels
> like worthwhile conservation of energy.
>
> Thoughts?
The framework is a good idea, but is somewhat poorly implemented. I'd
be quite interested in a generic system which took test cases in xml
and ran them using the implementation of choice. I think OpenAMQ may
have something similar. At the moment adding a test case is a lot of
work and ends up being duplicated across the different
implementations. This is a more general discussion though, we should
probably start a seperate thread.
>> - active commiters/contributers for the .NET
>> - known use cases we should address
>
> This might be a good question to ask on the user list.
Definatley. We have a few active users and contributors to the .Net client.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Re: Qpid .NET Strategy - Interested ?
Posted by Gordon Sim <gs...@redhat.com>.
Marnie McCormack wrote:
> We have (to the best of my knowledge) no requriements spec for either
> implementation, functional or non-functional.
I think the basic requirement for a client is to allow a user to exploit
the features of the protocol version in question.
There may be other relevant APIs for particular languages, so e.g. for
.Net WCF support might be an additional requirement. Of course there may
then be more detailed requirements about the mapping from the API in
question to AMQP.
> So, I think we need to discuss how we're taking the .NET client forward
> including:
> - identify what the key differences between the client implementations are
> (beyond protocol versions etc)
> - discuss migration paths for existing users
> - version negotiation/future proofing ?
I think the supported APIs are particularly relevant for these last two
items (API differences are probably a big part of the first item also).
> - testing, including the interop test runner integration
I've been meaning to comment on this more generally.
The examples that we have in python, c++ and JMS have been another way
of testing interoperability between clients. I think they currently
probably have at least as good coverage as the defined interop tests
(though at present the python examples are 0-10 only).
There are scripts for automated runs of the clients against each other
in all combinations. (In fact, we run the python and c++ ones as part of
the c++ 'make check').
I was very much in support of the interop framework approach, but with
the benefit of hindsight, the simpler approach followed in verifying the
examples has I think ended up being more successful.
We are always going to want to have examples to show users how to do
various things; we need to run those regularly in all combinations to
ensure they all work. Using that same approach for testing interop
between clients feels like worthwhile conservation of energy.
Thoughts?
> - active commiters/contributers for the .NET
> - known use cases we should address
This might be a good question to ask on the user list.
> At the end, I'd like us to have a strategy we are all happy with and a clear
> development roadmap for .NET users.
>
> Ideally this session would also allow some of our new windows developers to
> get involved and to influence what we're doing with the client.
I think it would be worth opening up some specific email debates on this
list and/or the user list. That doesn't prevent any telephone
conversations, but I think an email thread will have wider participation
and will consequently be a useful source of input.
> Hope this sheds some light,
Yes, very helpful. Thank you!
Re: Qpid .NET Strategy - Interested ?
Posted by Marnie McCormack <ma...@googlemail.com>.
Sure, we currently have two clients for .NET in Qpid - one for 0-8 and one
for 0-10. I know of several users of the 0-8 client, some of whom are
discussing their requirements for this year. I hope what follows is a
reasonably accurate picture of where we are now.
I think I'm on safe ground stating that the 0-8 client is getting pretty
rusty - it was essentially a port of the Java client at the time and has not
kept pace. It more or less does what it needs to for the existing users, but
it needs some significant attention to bring it up to speed. It also lacks
sufficient test cases/docs/etc.
The 0-10 client (afaik) is completely separate codebase and has recently had
a few teething issues. I know there were some discussions about the need
for test cases/docs/interop test integration etc. I'm not sure what the
outcome of these threads were, though I see there are some docs and info on
running tests on the wiki.
We have (to the best of my knowledge) no requriements spec for either
implementation, functional or non-functional.
So, I think we need to discuss how we're taking the .NET client forward
including:
- identify what the key differences between the client implementations are
(beyond protocol versions etc)
- discuss migration paths for existing users
- version negotiation/future proofing ?
- testing, including the interop test runner integration
- active commiters/contributers for the .NET
- known use cases we should address
At the end, I'd like us to have a strategy we are all happy with and a clear
development roadmap for .NET users.
Ideally this session would also allow some of our new windows developers to
get involved and to influence what we're doing with the client.
Hope this sheds some light,
Marnie
On Thu, Jan 8, 2009 at 10:08 AM, Gordon Sim <gs...@redhat.com> wrote:
> Marnie McCormack wrote:
>
>> We are currently in a somewhat interesting situation wrt to .NET clients
>> in
>> Qpid.
>>
>
> Could you elaborate on the issues?
>
Re: Qpid .NET Strategy - Interested ?
Posted by Gordon Sim <gs...@redhat.com>.
Marnie McCormack wrote:
> We are currently in a somewhat interesting situation wrt to .NET clients in
> Qpid.
Could you elaborate on the issues?
Re: Qpid .NET Strategy - Interested ?
Posted by Jonathan Robie <jo...@redhat.com>.
I'm interested.
Jonathan
Marnie McCormack wrote:
> All,
>
> We are currently in a somewhat interesting situation wrt to .NET clients in
> Qpid. I thought it might be helpful to get together the group of interested
> parties to agree the best way forward for the existing clients, and also to
> do some retrospective/forward looking requirements capture to help to
> clarify our aims.
>
> Can you reply if you'd be interested in attending a conference call to
> discuss this please ? We will (of course) post the notes/actions/decisions
> back to the list.
>
> I'll endeavour to make the session as widely attend-able as possible.
>
> Thanks & Regards,
> Marnie
>
>
RE: Qpid .NET Strategy - Interested ?
Posted by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>.
I would be very interested to join the conference call. Thanks.
Cliff
-----Original Message-----
From: Marnie McCormack [mailto:marnie.mccormack@googlemail.com]
Sent: Thursday, January 08, 2009 1:53 AM
To: qpid-dev@apache.org
Subject: Qpid .NET Strategy - Interested ?
All,
We are currently in a somewhat interesting situation wrt to .NET clients in
Qpid. I thought it might be helpful to get together the group of interested
parties to agree the best way forward for the existing clients, and also to
do some retrospective/forward looking requirements capture to help to
clarify our aims.
Can you reply if you'd be interested in attending a conference call to
discuss this please ? We will (of course) post the notes/actions/decisions
back to the list.
I'll endeavour to make the session as widely attend-able as possible.
Thanks & Regards,
Marnie