Qpid
  1. Qpid
  2. QPID-2589

Add a .NET binding to QPID Messaging API

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.7
    • Fix Version/s: 0.7
    • Component/s: C++ Client
    • Labels:
      None
    • Environment:

      Windows

      Description

      This binding package is a .NET Interop wrapper around the Qpid Messaging interface. It exposes the Messaging interface through a series of managed code classes that may be used by any .NET language.

      1. qpid-cpp-bindings_missing_functions.patch
        2 kB
        Chuck Rolke
      2. qpid_bindings.diff
        83 kB
        Chuck Rolke
      3. qpid_add_x86_platform.patch
        29 kB
        Chuck Rolke
      4. map_receiver_update.patch
        4 kB
        Chuck Rolke
      5. docbook-ProgrammingIn.patch
        61 kB
        Chuck Rolke
      6. cpp-bindings-dotnet_copyconstructor.patch
        15 kB
        Chuck Rolke
      7. cpp_bindings_qpid_dotnet-session-fix.patch
        3 kB
        Chuck Rolke
      8. cpp_bindings_qpid_dotnet_vb-helloworld-uuid.patch
        43 kB
        Chuck Rolke
      9. cpp_bindings_qpid_dotnet_use-properties.patch
        41 kB
        Chuck Rolke
      10. cpp_bindings_qpid_dotnet_update.patch
        100 kB
        Chuck Rolke
      11. cpp_bindings_qpid_dotnet__cleanup.patch
        101 kB
        Chuck Rolke
      12. cpp_binding_dotnet.patch
        19 kB
        Chuck Rolke

        Activity

        Hide
        Chuck Rolke added a comment -

        This code is inserted at cpp/bindings.

        Show
        Chuck Rolke added a comment - This code is inserted at cpp/bindings.
        Hide
        Cliff Jansen added a comment -

        This new C# API has good potential. I worry though about the choice of System.String as your starting point. Perhaps you meant to add eventually new constructors and methods to also match the existing C++:

        QPID_CLIENT_EXTERN Message(const char*, size_t);
        QPID_CLIENT_EXTERN void setContent(const char* chars, size_t count);

        in which case I think .NET folks would appreciate two options for each:

        Message(byte[] bytes);
        Message(byte[] bytes, int index, int count);
        SetContent(byte[] bytes)
        SetContent(byte[] bytes, int index, int count);

        In any event, it makes more sense that the System.String content be accessed or set via an encoder, as you probably intend to do for maps and other complex things. Keep in mind that std::string are a reasonable choice for manipulating binary content in C++. Trying to do the same thing with immutable Strings of 16 bit data is likely to cause severe brain strain during your implementation and .NET users won't thank you for your trouble.

        You might also want to tone down the C++-ness of the API, for example by using .NET naming conventions (i.e. case for methods), and using properties instead of methods for things like getMilliseconds() or setSubject().

        As a C++/CLI tip, be more defensive when passing responsibility for cleanup of native objects. I added the try block to your code

        Sender ^ Session::createSender (System::String ^ address)
        {
        // allocate a native sender
        ::qpid::messaging::Sender * senderp = new ::qpid::messaging::Sender;

        try

        { // create the sender *senderp = sessionp->::qpid::messaging::Session::createSender(QpidMarshal::ToNative(address)); // create a managed sender Sender ^ newSender = gcnew Sender(senderp, this); senderp = NULL; }

        finally {
        if (senderp !=NULL)

        { delete senderp }

        }

        return newSender;
        }

        Otherwise, if there is an exception in createSender() there is a memory leak. If there is an exception in the Sender() constructor, it is worse. There will be no finalizer call since the constructor didn't complete, so you wonder did it catch the exception and delete the native resource? The solution is for the receiver of the native object, Sender in this case, to take responsibility for cleanup only as the last thing before returning when an exception is no longer possible. In this particular case it works out that way because there are only memory assignments to existing memory. You should look at all the other cases where you do a similar handoff.

        Show
        Cliff Jansen added a comment - This new C# API has good potential. I worry though about the choice of System.String as your starting point. Perhaps you meant to add eventually new constructors and methods to also match the existing C++: QPID_CLIENT_EXTERN Message(const char*, size_t); QPID_CLIENT_EXTERN void setContent(const char* chars, size_t count); in which case I think .NET folks would appreciate two options for each: Message(byte[] bytes); Message(byte[] bytes, int index, int count); SetContent(byte[] bytes) SetContent(byte[] bytes, int index, int count); In any event, it makes more sense that the System.String content be accessed or set via an encoder, as you probably intend to do for maps and other complex things. Keep in mind that std::string are a reasonable choice for manipulating binary content in C++. Trying to do the same thing with immutable Strings of 16 bit data is likely to cause severe brain strain during your implementation and .NET users won't thank you for your trouble. You might also want to tone down the C++-ness of the API, for example by using .NET naming conventions (i.e. case for methods), and using properties instead of methods for things like getMilliseconds() or setSubject(). As a C++/CLI tip, be more defensive when passing responsibility for cleanup of native objects. I added the try block to your code Sender ^ Session::createSender (System::String ^ address) { // allocate a native sender ::qpid::messaging::Sender * senderp = new ::qpid::messaging::Sender; try { // create the sender *senderp = sessionp->::qpid::messaging::Session::createSender(QpidMarshal::ToNative(address)); // create a managed sender Sender ^ newSender = gcnew Sender(senderp, this); senderp = NULL; } finally { if (senderp !=NULL) { delete senderp } } return newSender; } Otherwise, if there is an exception in createSender() there is a memory leak. If there is an exception in the Sender() constructor, it is worse. There will be no finalizer call since the constructor didn't complete, so you wonder did it catch the exception and delete the native resource? The solution is for the receiver of the native object, Sender in this case, to take responsibility for cleanup only as the last thing before returning when an exception is no longer possible. In this particular case it works out that way because there are only memory assignments to existing memory. You should look at all the other cases where you do a similar handoff.
        Hide
        Chuck Rolke added a comment -

        Thanks for the comments.

        • Raw byte[] interface - will do
        • .Net naming/use of properties - will do
        • defensive code/memory leaks - hadn't gotten to that yet, but you're right and will do.

        The up-and-coming interface to Variant::List and Variant::Map will probably look like the following pseudo-code:

        //
        // Create structured content for the message. This example builds a
        // map of items including a nested map and a list of values.
        //
        Dictionary<string, object> content = new Dictionary<string, object>();
        Dictionary<string, object> subMap = new Dictionary<string, object>();
        List<object> colors = new List<object>();

        content["id"] = 987654321;
        content["name"] = "Widget";
        content["percent"] = 0.99;

        submap["name"] = "Smith";
        submap["number"] = 354;

        content["nested"] = submap;

        colors.Add("red");
        colors.Add("green");
        colors.Add("white");

        content["colors"] = colors;

        //
        // Construct a message with the map content and send it synchronously
        // via the sender.
        //
        Message message = new Message(content);
        sender.send(message, true);

        Do you think Dictionary and List objects are the best choices?

        Show
        Chuck Rolke added a comment - Thanks for the comments. Raw byte[] interface - will do .Net naming/use of properties - will do defensive code/memory leaks - hadn't gotten to that yet, but you're right and will do. The up-and-coming interface to Variant::List and Variant::Map will probably look like the following pseudo-code: // // Create structured content for the message. This example builds a // map of items including a nested map and a list of values. // Dictionary<string, object> content = new Dictionary<string, object>(); Dictionary<string, object> subMap = new Dictionary<string, object>(); List<object> colors = new List<object>(); content ["id"] = 987654321; content ["name"] = "Widget"; content ["percent"] = 0.99; submap ["name"] = "Smith"; submap ["number"] = 354; content ["nested"] = submap; colors.Add("red"); colors.Add("green"); colors.Add("white"); content ["colors"] = colors; // // Construct a message with the map content and send it synchronously // via the sender. // Message message = new Message(content); sender.send(message, true); Do you think Dictionary and List objects are the best choices?
        Hide
        Gordon Sim added a comment -

        Would it be possible to build the WCF (channel and service interfaces) on top of this API?

        Show
        Gordon Sim added a comment - Would it be possible to build the WCF (channel and service interfaces) on top of this API?
        Hide
        Rajith Attapattu added a comment -

        I noticed that the binding lives inside the cpp dir.
        I would assume this is temporary and that it will eventually be moved out to a suitable location?

        Show
        Rajith Attapattu added a comment - I noticed that the binding lives inside the cpp dir. I would assume this is temporary and that it will eventually be moved out to a suitable location?
        Hide
        Cliff Jansen added a comment -

        > Would it be possible to build the WCF (channel and service
        > interfaces) on top of this API?

        Well, no. But that is the same answer for the old 0-10 client code and, nevertheless, the WCF channel uses that for 95% of its work and sneaks around it for some additional functionality.

        In the end, this new API is much less rich, which means the WCF channel may have to work much harder behind the scenes to get its work done. But that still may be the right balance. The API should be true to the target developer base first - how many need to be transaction resource managers or perftest stars?

        The major outages are dtx support and message body content optimizations (one time set, one time retrieve, i.e. the WCF paradigm, and I would argue a not uncommon scenario).

        Off the top of my head, I also worry about the limited async functionality. The current WCF implementation relies heavily on async related classes in the old API, such as Future and Completion. Their absence in this API is not fatal ("just" run another thread to block on a session.sync(true)), but reduces options for performance optimizations. The current WCF implementation is impressively speedy and it would be sad to handicap it.

        I would be most happy to see things evolve so that the messaging API becomes a libc-ish entity that can work in an application that simultaneously uses kernel-ish functionality for finer grained capabilities (without pulling the rug out from under libc). I am all for keeping the "Advanced" in AMQP.

        Show
        Cliff Jansen added a comment - > Would it be possible to build the WCF (channel and service > interfaces) on top of this API? Well, no. But that is the same answer for the old 0-10 client code and, nevertheless, the WCF channel uses that for 95% of its work and sneaks around it for some additional functionality. In the end, this new API is much less rich, which means the WCF channel may have to work much harder behind the scenes to get its work done. But that still may be the right balance. The API should be true to the target developer base first - how many need to be transaction resource managers or perftest stars? The major outages are dtx support and message body content optimizations (one time set, one time retrieve, i.e. the WCF paradigm, and I would argue a not uncommon scenario). Off the top of my head, I also worry about the limited async functionality. The current WCF implementation relies heavily on async related classes in the old API, such as Future and Completion. Their absence in this API is not fatal ("just" run another thread to block on a session.sync(true)), but reduces options for performance optimizations. The current WCF implementation is impressively speedy and it would be sad to handicap it. I would be most happy to see things evolve so that the messaging API becomes a libc-ish entity that can work in an application that simultaneously uses kernel-ish functionality for finer grained capabilities (without pulling the rug out from under libc). I am all for keeping the "Advanced" in AMQP.
        Hide
        Gordon Sim added a comment -

        > The major outages are dtx support and message body content optimizations (one time set, one time retrieve, i.e. the WCF paradigm, and I would argue a not uncommon scenario).

        These are certainly gaps we would want to address in the messaging API and its implementation.

        > Off the top of my head, I also worry about the limited async functionality. The current WCF implementation relies heavily on async related classes in the old API, such as Future and Completion.

        I'd be keen to explore these worries in some more detail. Could we tackle one or two concrete cases to begin with?

        Show
        Gordon Sim added a comment - > The major outages are dtx support and message body content optimizations (one time set, one time retrieve, i.e. the WCF paradigm, and I would argue a not uncommon scenario). These are certainly gaps we would want to address in the messaging API and its implementation. > Off the top of my head, I also worry about the limited async functionality. The current WCF implementation relies heavily on async related classes in the old API, such as Future and Completion. I'd be keen to explore these worries in some more detail. Could we tackle one or two concrete cases to begin with?
        Hide
        Cliff Jansen added a comment -

        One problem is implementing WCF's BeginSend for asynchronous writes. There are three ways of using them, two shown here:

        // nothing blocks
        IOutputChannel myChannel;
        AsyncCallback sendCallback = new AsyncCallback(this.MyCallback);

        // ...
        for (i=0; i<msgcount; i++)

        { msg = myMessageFactory.Create("in loop with callback", i); myChannel.BeginSend(msg, TimeSpan.MaxValue, mycallbackDelegate, msg); }

        // alternate use
        msg = myMessageFactory.Create("polling", 0);
        IAsyncResult result = myChannel.BeginSend(msg, TimeSpan.MaxValue, null, null);
        while (!result.IsComplete)

        { // do something else }

        myChannel.EndSend(result); // could raise exception here
        msg.Close();

        //...

        void MyCallback(IAsyncResult result) {
        Message msg = (Message) result.AsyncState;
        try

        { myChannel.EndSend(result); }

        catch (Exception e) {
        Console.WriteLine("message send exception

        {0}

        ", e);
        }

        msg.Close();
        }

        I can't see how to implement this functionality in the new messaging API without launching a thread to monitor a write(msg, true) for every BeginSend. In the 0-10 API, I have a single thread that monitors an ordered list of Future objects:

        futurep = new Future(sessionImplp->send(mtcmd, *framesetp));

        If there is exception or connection drop, the Future preserves information to know which messages succeeded and which ones failed.

        WcfPerftest with a million messages and a million separate thread instances would not be pretty, even if they come from a thread pool.

        Looking through the existing WCF implementation, the only other Futures that are used are for XaResults from the various dtx commands. It would be nice to be able to preserve the async nature for these in the new API going forward. I think any resource manager would want to have this capability.

        Show
        Cliff Jansen added a comment - One problem is implementing WCF's BeginSend for asynchronous writes. There are three ways of using them, two shown here: // nothing blocks IOutputChannel myChannel; AsyncCallback sendCallback = new AsyncCallback(this.MyCallback); // ... for (i=0; i<msgcount; i++) { msg = myMessageFactory.Create("in loop with callback", i); myChannel.BeginSend(msg, TimeSpan.MaxValue, mycallbackDelegate, msg); } // alternate use msg = myMessageFactory.Create("polling", 0); IAsyncResult result = myChannel.BeginSend(msg, TimeSpan.MaxValue, null, null); while (!result.IsComplete) { // do something else } myChannel.EndSend(result); // could raise exception here msg.Close(); //... void MyCallback(IAsyncResult result) { Message msg = (Message) result.AsyncState; try { myChannel.EndSend(result); } catch (Exception e) { Console.WriteLine("message send exception {0} ", e); } msg.Close(); } I can't see how to implement this functionality in the new messaging API without launching a thread to monitor a write(msg, true) for every BeginSend. In the 0-10 API, I have a single thread that monitors an ordered list of Future objects: futurep = new Future(sessionImplp->send(mtcmd, *framesetp)); If there is exception or connection drop, the Future preserves information to know which messages succeeded and which ones failed. WcfPerftest with a million messages and a million separate thread instances would not be pretty, even if they come from a thread pool. Looking through the existing WCF implementation, the only other Futures that are used are for XaResults from the various dtx commands. It would be nice to be able to preserve the async nature for these in the new API going forward. I think any resource manager would want to have this capability.
        Hide
        Cliff Jansen added a comment -

        A timeout for send() (to match get() and fetch()) would be useful to WCF since the call can block. Does this seem useful in general?

        Is there an async receive existing or planned like the older MessageListener?

        I see the nextReceiver() call, but as I see it, this requires a dedicated thread per Session to poll for the client's next message, whereas the 0-10 allowed a single thread or small pool to service the handed off message from all sessions.

        Show
        Cliff Jansen added a comment - A timeout for send() (to match get() and fetch()) would be useful to WCF since the call can block. Does this seem useful in general? Is there an async receive existing or planned like the older MessageListener? I see the nextReceiver() call, but as I see it, this requires a dedicated thread per Session to poll for the client's next message, whereas the 0-10 allowed a single thread or small pool to service the handed off message from all sessions.
        Hide
        Gordon Sim added a comment -

        > I see the nextReceiver() call, but as I see it, this requires a dedicated thread per Session to poll for the client's next message, whereas the 0-10 allowed a single thread or small pool to service the handed off message from all sessions.

        Actually I don't think that is correct, the old 0-10 API also required a thread per session, at least at the c++ level. However going forward we do want to change that. One of the problems was the lack of support from the old client (in those parts on which the new client was built).

        I'll work through your examples on async send above, thanks for posting them!

        Show
        Gordon Sim added a comment - > I see the nextReceiver() call, but as I see it, this requires a dedicated thread per Session to poll for the client's next message, whereas the 0-10 allowed a single thread or small pool to service the handed off message from all sessions. Actually I don't think that is correct, the old 0-10 API also required a thread per session, at least at the c++ level. However going forward we do want to change that. One of the problems was the lack of support from the old client (in those parts on which the new client was built). I'll work through your examples on async send above, thanks for posting them!
        Hide
        Cliff Jansen added a comment -

        > Dictionary<string, object> content = new Dictionary<string, object>();
        [...]
        > List<object> colors = new List<object>();
        [...]
        > Do you think Dictionary and List objects are the best choices?

        The C++ implementation is more stringent. To match it more closely in semantics, I wonder whether you mean to use AmqpType instead of "object" above, or create a new Class named Variant to match the C++ implementation.

        I think AmqpType is the more descriptive name, but consistent naming across clients may be the more important goal here.

        Otherwise I think you definitely want to use Dictionaries and Lists.

        Show
        Cliff Jansen added a comment - > Dictionary<string, object> content = new Dictionary<string, object>(); [...] > List<object> colors = new List<object>(); [...] > Do you think Dictionary and List objects are the best choices? The C++ implementation is more stringent. To match it more closely in semantics, I wonder whether you mean to use AmqpType instead of "object" above, or create a new Class named Variant to match the C++ implementation. I think AmqpType is the more descriptive name, but consistent naming across clients may be the more important goal here. Otherwise I think you definitely want to use Dictionaries and Lists.
        Hide
        Chuck Rolke added a comment -

        Additional logic for POC.

        Rooted at cpp/qpid/bindings/qpid/dotnet/src.

        This patch adds support for most native types and supports the .NET Dictionary and List objects as containers for Qpid Map and List data.

        Note that none of the improvement suggestions to date are implemented. This patch is still more on the proof-of-concept track.

        Show
        Chuck Rolke added a comment - Additional logic for POC. Rooted at cpp/qpid/bindings/qpid/dotnet/src. This patch adds support for most native types and supports the .NET Dictionary and List objects as containers for Qpid Map and List data. Note that none of the improvement suggestions to date are implemented. This patch is still more on the proof-of-concept track.
        Hide
        Ted Ross added a comment -

        >> I noticed that the binding lives inside the cpp dir.
        >> I would assume this is temporary and that it will eventually be moved out to a suitable location?

        Actually, I claim that this is where it belongs. This contribution is simply a .NET binding to the C++ messaging API. It allows .net applications in C#, VB, etc. to access the messaging API. No more, no less.

        The advantage of this contribution is that it is very supportable because it leverages the C++ client and adds very little logic. It is not in the same category as the WCF code which is adding a large amount of useful functionality on top of messaging.

        It will, hopefully, make the qpid/dotnet API obsolete.

        -Ted

        Show
        Ted Ross added a comment - >> I noticed that the binding lives inside the cpp dir. >> I would assume this is temporary and that it will eventually be moved out to a suitable location? Actually, I claim that this is where it belongs. This contribution is simply a .NET binding to the C++ messaging API. It allows .net applications in C#, VB, etc. to access the messaging API. No more, no less. The advantage of this contribution is that it is very supportable because it leverages the C++ client and adds very little logic. It is not in the same category as the WCF code which is adding a large amount of useful functionality on top of messaging. It will, hopefully, make the qpid/dotnet API obsolete. -Ted
        Hide
        Ted Ross added a comment -

        Expanding on my last comment...

        The .net code in this binding should never add any "messaging" value to the API. If we want to add new features, they should first be added to the C++ messaging API and then reflected through this binding.

        Also, with regard to the location of this code... The "bindings" directory under qpid/cpp is intended to hold other-language bindings to C++ interfaces. We might want to eventually supply messaging bindings for Python, Ruby, Perl, PHP, etc. so that these interfaces can be more easily supported and can benefit from the features and performance of the C++ API.

        -Ted

        Show
        Ted Ross added a comment - Expanding on my last comment... The .net code in this binding should never add any "messaging" value to the API. If we want to add new features, they should first be added to the C++ messaging API and then reflected through this binding. Also, with regard to the location of this code... The "bindings" directory under qpid/cpp is intended to hold other-language bindings to C++ interfaces. We might want to eventually supply messaging bindings for Python, Ruby, Perl, PHP, etc. so that these interfaces can be more easily supported and can benefit from the features and performance of the C++ API. -Ted
        Hide
        Chuck Rolke added a comment -

        Add decode logic to csharp.map.receiver.cs to recursively display message structure, values, and type codes.

        Rooted at qpid/cpp/bindings/qpid/examples/csharp.map.receiver

        Show
        Chuck Rolke added a comment - Add decode logic to csharp.map.receiver.cs to recursively display message structure, values, and type codes. Rooted at qpid/cpp/bindings/qpid/examples/csharp.map.receiver
        Hide
        Gordon Sim added a comment -

        Re implementing "WCF's BeginSend for asynchronous writes", one suggestion for that is to maintain a counter for each sender tracking the messages sent. The AsyncResult for a BeginSend would then include the value of the counter for that send, lets call it x. If for any given send, counter - sender.getUnsettled() > x, that send has completed. Does that sound workable?

        You would still want a way to wait for changes to the unsettled list. The desire to improve the general threading by adding some generic mechanisms like this has been discussed and should be a future focus for the messaging API. However I don't think the messaging API is any worse in this respect than the old 0-10 API which required either busy-polling or syncing.

        Note also that with the messaging API the replaying of messages would be part of the underlying functionality.

        Show
        Gordon Sim added a comment - Re implementing "WCF's BeginSend for asynchronous writes", one suggestion for that is to maintain a counter for each sender tracking the messages sent. The AsyncResult for a BeginSend would then include the value of the counter for that send, lets call it x. If for any given send, counter - sender.getUnsettled() > x, that send has completed. Does that sound workable? You would still want a way to wait for changes to the unsettled list. The desire to improve the general threading by adding some generic mechanisms like this has been discussed and should be a future focus for the messaging API. However I don't think the messaging API is any worse in this respect than the old 0-10 API which required either busy-polling or syncing. Note also that with the messaging API the replaying of messages would be part of the underlying functionality.
        Hide
        Cliff Jansen added a comment -

        Thank-you Gordon for turning your mind to this.

        > You would still want a way to wait for changes to the unsettled list.

        Much better would be an event notification, see below. But otherwise, that plus "sender.getUnsettled() > x" should do the trick.

        > However I don't think the messaging API is any worse in this respect
        > than the old 0-10 API which required either busy-polling or syncing.

        Well, the WCF channel uses Future.wait() which is better than either of those options. Even that strategy was criticized during WCF design meetings at Microsoft as "wasting" a thread resource for each session that witnessed async writes (imagining an application that might simultaneously be servicing 100's or thousands of sessions).

        A better pattern for high performance WCF would be to be able to register for notification of various events, such as message arrival, command completion (for message send and dtxFoo) that arrive in the context of the Windows IO completion port thread that the socket implementation manages. This may matter much less on Linux, but I expect there would still be a class of developers who would appreciate some form of event notification.

        Show
        Cliff Jansen added a comment - Thank-you Gordon for turning your mind to this. > You would still want a way to wait for changes to the unsettled list. Much better would be an event notification, see below. But otherwise, that plus "sender.getUnsettled() > x" should do the trick. > However I don't think the messaging API is any worse in this respect > than the old 0-10 API which required either busy-polling or syncing. Well, the WCF channel uses Future.wait() which is better than either of those options. Even that strategy was criticized during WCF design meetings at Microsoft as "wasting" a thread resource for each session that witnessed async writes (imagining an application that might simultaneously be servicing 100's or thousands of sessions). A better pattern for high performance WCF would be to be able to register for notification of various events, such as message arrival, command completion (for message send and dtxFoo) that arrive in the context of the Windows IO completion port thread that the socket implementation manages. This may matter much less on Linux, but I expect there would still be a class of developers who would appreciate some form of event notification.
        Hide
        Gordon Sim added a comment -

        > A better pattern for high performance WCF would be to be able to register for notification of various events, such as message arrival, command completion (for message send and dtxFoo) that arrive in the context of the
        > Windows IO completion port thread that the socket implementation manages. This may matter much less on Linux, but I expect there would still be a class of developers who would appreciate some form of event
        > notification.

        Agreed; better integration into event loops is certainly important and the API will be extended for that.

        Show
        Gordon Sim added a comment - > A better pattern for high performance WCF would be to be able to register for notification of various events, such as message arrival, command completion (for message send and dtxFoo) that arrive in the context of the > Windows IO completion port thread that the socket implementation manages. This may matter much less on Linux, but I expect there would still be a class of developers who would appreciate some form of event > notification. Agreed; better integration into event loops is certainly important and the API will be extended for that.
        Hide
        Chuck Rolke added a comment -

        This patch provides a nearly feature-complete .NET binding to the cpp Messaging interface.

        The patch is rooted at qpid/cpp/bindings/qpid/dotnet.

        Issues to be resolved include:

        • some pointers are public and should be private
        • String encoding from/to user .NET space is all UTF-8. Other encodings and raw message support needed.
        • try/catch strategy needs to be finalized
        • Object copying needs to be controlled better.
        Show
        Chuck Rolke added a comment - This patch provides a nearly feature-complete .NET binding to the cpp Messaging interface. The patch is rooted at qpid/cpp/bindings/qpid/dotnet. Issues to be resolved include: some pointers are public and should be private String encoding from/to user .NET space is all UTF-8. Other encodings and raw message support needed. try/catch strategy needs to be finalized Object copying needs to be controlled better.
        Hide
        Chuck Rolke added a comment -

        This patch coerces the solution to produce DLLs and EXEs that compile and/or run on 32-bit or 64-bit systems interchangeably.

        Show
        Chuck Rolke added a comment - This patch coerces the solution to produce DLLs and EXEs that compile and/or run on 32-bit or 64-bit systems interchangeably.
        Hide
        Chuck Rolke added a comment -

        Cleanup pass to address function naming, capitalization rules, change Qpid messaging 'list' representation from List<> to Collection<>, some exception cleanup.

        Show
        Chuck Rolke added a comment - Cleanup pass to address function naming, capitalization rules, change Qpid messaging 'list' representation from List<> to Collection<>, some exception cleanup.
        Hide
        Chuck Rolke added a comment -
        • Create sender and receiver using Address arg.
        • Create messages from raw byte array or from raw byte array slice.
        • Map sender examples send all supported data types.
        • Add interop client/server and drain/spout examples.
        • Add declare_queues utility.
        • Add AsString() function to show amqp/map and amqp/list objects on the console.
        Show
        Chuck Rolke added a comment - Create sender and receiver using Address arg. Create messages from raw byte array or from raw byte array slice. Map sender examples send all supported data types. Add interop client/server and drain/spout examples. Add declare_queues utility. Add AsString() function to show amqp/map and amqp/list objects on the console.
        Hide
        Chuck Rolke added a comment -

        Add visualbasic.example.client which is a clone of csharp.example.client. Demonstrates how easily CSharp will port to VisualBasic.

        Show
        Chuck Rolke added a comment - Add visualbasic.example.client which is a clone of csharp.example.client. Demonstrates how easily CSharp will port to VisualBasic.
        Hide
        Chuck Rolke added a comment -

        This patch obsoletes patch dated 2010-06-15 (which never got applied). This patch contains that patch plus:

        1. Adds Hello World example described in the doc book.
        2. Adds missing UUID variant data type.

        Show
        Chuck Rolke added a comment - This patch obsoletes patch dated 2010-06-15 (which never got applied). This patch contains that patch plus: 1. Adds Hello World example described in the doc book. 2. Adds missing UUID variant data type.
        Hide
        Cliff Jansen added a comment -

        If I add the following to the map example:

        byte[] myBytes = new byte[3]

        { 102, 111, 111}

        ;
        content["myBytes"] = byBytes;

        I get a NotImplementedException. Is this a known todo item?

        Presumably the dotnet map implementation is intended to interoperate with the Java MapMessage, including distinguishing between getBytes(), getString() [ and setBytes(), setString()].

        Show
        Cliff Jansen added a comment - If I add the following to the map example: byte[] myBytes = new byte [3] { 102, 111, 111} ; content ["myBytes"] = byBytes; I get a NotImplementedException. Is this a known todo item? Presumably the dotnet map implementation is intended to interoperate with the Java MapMessage, including distinguishing between getBytes(), getString() [ and setBytes(), setString()].
        Hide
        Chuck Rolke added a comment -

        > If I add the following to the map example:
        >
        > byte[] myBytes = new byte[3]

        { 102, 111, 111};
        > content["myBytes"] = byBytes;
        >
        > I get a NotImplementedException. Is this a known todo item?

        In today's code the following mapping is in place:

        amqp/map - Dictionary<string, object>
        amqp/list - Collection<object>

        The syntax you are trying to use is not yet supported. To get your data into the map try:

        byte[] myBytes = new byte[3] { 102, 111, 111}

        ;
        Collection<object> cBytes = new Collection<object>();
        for (int i=0; i<myBytes.Length; i++)
        cBytes.Add(myBytes[i]);
        content["myBytes"] = cBytes;

        In today's implementation a managed code a Collection<object>, where object items are supported primitive types, gets converted into a C++ Variant::List, and then into an amqp/list to the broker.

        The syntax you are trying is a fluent way of expressing a list at least for data going into a message and should be considered for inclusion in the message encoder. For received messages, though, the Collection<object> works better as items in an amqp/list may be of mixed types.

        Show
        Chuck Rolke added a comment - > If I add the following to the map example: > > byte[] myBytes = new byte [3] { 102, 111, 111}; > content ["myBytes"] = byBytes; > > I get a NotImplementedException. Is this a known todo item? In today's code the following mapping is in place: amqp/map - Dictionary<string, object> amqp/list - Collection<object> The syntax you are trying to use is not yet supported. To get your data into the map try: byte[] myBytes = new byte [3] { 102, 111, 111} ; Collection<object> cBytes = new Collection<object>(); for (int i=0; i<myBytes.Length; i++) cBytes.Add(myBytes [i] ); content ["myBytes"] = cBytes; In today's implementation a managed code a Collection<object>, where object items are supported primitive types, gets converted into a C++ Variant::List, and then into an amqp/list to the broker. The syntax you are trying is a fluent way of expressing a list at least for data going into a message and should be considered for inclusion in the message encoder. For received messages, though, the Collection<object> works better as items in an amqp/list may be of mixed types.
        Hide
        Chuck Rolke added a comment -
        • Convert c-style Get() functions to c#-style properties.
        • Add powershell helloworld example.
        • Fix message SetContent to accept byte array or byte array slice.
        • Re-code Session GetReceiver and GetSender not to malloc new objects but to create the objects on the stack.
        Show
        Chuck Rolke added a comment - Convert c-style Get() functions to c#-style properties. Add powershell helloworld example. Fix message SetContent to accept byte array or byte array slice. Re-code Session GetReceiver and GetSender not to malloc new objects but to create the objects on the stack.
        Hide
        Chuck Rolke added a comment -

        Re-do changes to Session.cpp.

        Show
        Chuck Rolke added a comment - Re-do changes to Session.cpp.
        Hide
        Chuck Rolke added a comment -

        Rooted at qpid/cpp/bindings/qpid/dotnet, this patch cleans up or adds the copy constructors and the copy assignment operators for the binding classes.

        Every managed class object must have a pointer to a different unmanaged class object. The unmanaged class objects can not be shared among managed class objects.

        Show
        Chuck Rolke added a comment - Rooted at qpid/cpp/bindings/qpid/dotnet, this patch cleans up or adds the copy constructors and the copy assignment operators for the binding classes. Every managed class object must have a pointer to a different unmanaged class object. The unmanaged class objects can not be shared among managed class objects.
        Hide
        Chuck Rolke added a comment -

        Rooted at trunk/qpid, this patch adds a detailed description of the C++ Messaging .NET Binding programming interface.

        Rather than rewriting all of the C++ interface details, this chapter lists each function's syntax for C++ and for .NET in a set of tables. One may read about how the C++ interface works and then apply the same principles to the .NET binding using the .NET syntax.

        Show
        Chuck Rolke added a comment - Rooted at trunk/qpid, this patch adds a detailed description of the C++ Messaging .NET Binding programming interface. Rather than rewriting all of the C++ interface details, this chapter lists each function's syntax for C++ and for .NET in a set of tables. One may read about how the C++ interface works and then apply the same principles to the .NET binding using the .NET syntax.
        Hide
        Chuck Rolke added a comment -

        Rooted at qpid/cpp/bindings/, this patch fixes a property misspelling and adds two missing functions. These errors and omissions were found during the generation of the docbook tables.

        Show
        Chuck Rolke added a comment - Rooted at qpid/cpp/bindings/, this patch fixes a property misspelling and adds two missing functions. These errors and omissions were found during the generation of the docbook tables.

          People

          • Assignee:
            Ted Ross
            Reporter:
            Chuck Rolke
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development