@SteveChandler wrote:
I would like comments from people who do not use it. I am mostly looking for negatives.
Sorry to disappoint, but I don't have anything negative to say about the AMC. The best feedback you'll get is from people who use the AMC, and if they use it they're not likely to have a lot of negative things to say about it. There are significant differences between the AMC and LapDog's Messaging Library ("LDM" from here on out) but categorizing each feature as positive or negative is subjective and depends a lot on project requirements and personal preference.
Before I comment on the main differences, let me state that I have played with the AMC a few times but I have never used it as part of a real application. On the other hand, I use the LDM all the time. It's a foundational part of everything I write. I can speak to the intent and purpose of the LDM--the AMC... not so much. Maybe Christian, who I believe wrote the AMC, will chime in.
Paradigm
The most obvious difference is the programming paradigm used. LDM is object-oriented; AMC is procedural. If you're trying to decide between which of the two to use, that's as likely as anything to be the determining factor.
In the LDM all messages are instances of, or children of, Message.lvclass. Sending data with a message requires you to create a subclass. In the AMC the message's user data is flattened to a string before being queued up. Object-based messages provide better type-safety. String-based messages are faster to implement. Whatever you do, I highly recommend using a single messaging system in your app. Mixing incompatible systems gets very messy very quickly.
Scope
The AMC is far more ambitious that the LDM. It permits messages to be sent locally or over the network in a way that appears to be mostly transparent to the user. The LDM limits its scope to the types of things queues are normally restricted to. Native queues don't work over the network; neither does the LDM. This is a difference in design philosophy more than anything.
I prefer my reusable foundation classes to be small and highly cohesive. I'll create more complex functionality by combining foundational classes into application-specific mid-level classes (object composition) that are in turn used by the high-level application code. The AMC is roughly equivalent to the mid-level class I would get if I combined a local messaging class with UDP network messaging class.
Dequeue
This is a minor difference, but it is one of my favorite things about the LDM (though it is by no means unique to the LDM.) LDM's Dequeue method traps errors and the Timed Out flag and returns them as predefined messages instead of requiring you to specifically test for them. In my message handling case structure I add cases for "QueueErrorMessage", "QueueErrorInMessage", and "QueueTimeoutMessage". I think it makes my code a lot cleaner and easier to follow.
Subjective Conclusion
LDM was written when I became dissatisfied with string-variant messaging systems. It is a thin wrapper around native queues and intended to be a general purpose messaging system for object-oriented programmers. I suspect (but don't know) the AMC was written specifically for apps that communicate with real time systems. I also suspect (but don't know) that it is very good at doing that.
The tradeoffs? If the AMC meets the needs of your project, it will be very useful. If it doesn't, it's probably nearly useless. For example, what if my network communication needs to use TCP instead of UDP? The source code is in user.lib, so I can't arbitrarily change it for this project. I could make an app-specific copy of the code and customize it, but if I have to do that every time the AMC needs a little tweak it kind of defeats the purpose of a reuse library. Also, if you don't need everything the AMC provides you can end up carrying around a lot of stuff you don't need.
On the other hand, the LDM faces the same obstacles all OO code does. OOP in general creates more layers to drill through before you get to the part that actually does something. Lots of people don't like that and find it more confusing. It also often requires more files on disk than the equivalent procedural code, which is another stumbling block for many. I believe there are some NI technologies that don't support objects yet, like network streams.
At the end of the day you can probably use either one provided you're willing to learn the api.
[Note: I recently posted some LDM details on Lava.]
