Hi Gordon, > I'd be keen to hear more of your thoughts an opinions on the new API > for the c++ client.
I will try to take another look at it shortly. > It would be worth seeing if we can get better alignment between the > examples for all languages. Agreed. I will do my best to make the upcoming interop examples resemble the main C++ and Java examples in structure as much as WCF allows. > Documentation of some form would be really great [...] Absolutely. This is a known major outage and is just as high a priority for us as the functional feature work. > I notice for example you use uris that look similar to the JMS > "binding urls". Is the same syntax supported? There are some usability > issues with that format (in my opinion), especially when using more > complex patterns. I believe there are very few similarities. The WCF model specifies the connection properties to servers (i.e. brokers) in a separate Binding which can be arbitrarily complex and already has established conventions for specifying many network related properties either programmatically or within XML config files. The actual uris in the WCF client specify the minimum to identify a queue or exchange + routing key pair. A similar mechanism, with slight variation, will probably be proposed for use with AMQP 1.0. Cliff -----Original Message----- From: Gordon Sim [mailto:g...@redhat.com] Sent: Friday, February 05, 2010 4:19 AM To: dev@qpid.apache.org Subject: Re: WCF/C++ client feature work for 0.7 Thanks for the info, Cliff! You've done some great work on this. On 02/04/2010 07:54 PM, Cliff Jansen (Interop Systems Inc) wrote: > The existing 0.6 version of the WCF/C++ client provides basic WCF > functionality. Its most significant additional feature is distributed > transaction support for enterprise applications. The WCF channel > portion relies on the well tested and high performance C++ native > client libraries for most of the logic at the transport and session > layers. The current status and future wish list are summarized in the > top-level ReadMe.txt file. I'd be keen to hear more of your thoughts an opinions on the new API for the c++ client. Though the existing 0-10 specific API will remain, I anticipate improvements and added features via the new API (producer flow control for example, and it already has built in reconnection and replay logic). > The long term goal of the WCF channel is to provide .NET programmers > with a full featured AMQP messaging client. To maximize adoption, it > uses the same programming model used by the Microsoft WCF channel > implementations for messaging over MSMQ and over WebSphere MQ. To > maximize functionality, it incorporates or has planned features for > AMQP specific capabilities (such as local transactions which will > require some magic to associate separate WCF channels with a single > AMQP session). > > A further goal is to maximize the interoperability of the WCF channel > with other AMQP clients by providing full access to AMQP types in > message headers and the message body. In 0.6 it is possible to > exchange int and string properties between JMS and WCF clients. Text > and binary content can also be shared between clients as demonstrated > by the WcfPerftest sample program. Expanding this to include all JMS > message properties and supporting AMQP map messages is proposed as a > high priority improvement for the WCF channel in the 0.7 timeframe > (consistent with the goals of QPID-2226). It would be worth seeing if we can get better alignment between the examples for all languages. That's a great way to demonstrate the basic interoperability and is especially helpful when for clients with quite different programming models. Documentation of some form would be really great (even if its links elsewhere) on that front also. The samples are really quite different to those for the other clients. I don't have previous experience of WCF, and it may be more obvious to those that do. Even there though some description of the mapping of WCF to AMQP would be important. I notice for example you use uris that look similar to the JMS "binding urls". Is the same syntax supported? There are some usability issues with that format (in my opinion), especially when using more complex patterns. --------------------------------------------------------------------- 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
