New icons for Messenger Library

[drjdpowell]

I have put some effort into improving the VI icons in Messenger Library, in hopes of making things clearer.  I have particularly been trying to get rid of the magnifying glass icon, which was standing in for too many concepts.   I have also tried to improve the Palettes by putting the standard VIs (that one would most commonly use) in the root-level palette:

The 2.0 version also introduces Malleable API methods (the orange-coloured ones), which make code cleaner.

If anyone could spare some time, it would help me to have feedback.  Especially from people who have not used Messenger Library before, so I can get an idea if the key concepts come across.  I have also rewritten the VIPM description:

Advanced messaging made simple!

Messenger Library is a library for message passing using a variety of powerful Messaging Patterns, and a set of Templates for easily creating parallel modules to interact with those Patterns.  Together, these comprise a powerful and deep framework for rapid application development.

Communication patterns supported and other features include:

   -- Request-and-wait-for-Reply

   -- Asynchronous Request-Reply, where the reply is sent to a "reply address" attached to the request

   -- Scatter-Gather: Requests sent to multiple addresses, with all Replies gathered together in order

   -- Register-Notify, where one process sends a registration message to another in order to subscribe to published messages.   

   -- Future Token, a reference to a future Reply not yet made

   -- Asynchronous Dialog: query the User without blocking (User's response sent as a message)

   -- Delayed Request: message sent with a set asynchronous delay

   -- Metronome, a source of precisely-timed periodic messages

   -- Timeout Watchdog: trigger an action if something expected doesn't happen

Freely intermix communication by Queues, User Events or Notifiers.

First-class support for TCP communication, allowing easy interaction of multiple executables using any of the Messaging Patterns.   Also supports UDP, including multicast.

Module Templates are simple, consisting of a single VI and a single loop, and are robust against race conditions (unlike the more complex "Producer Consumer" NI templates).

Includes two utilities under the menu "Tools>>Messenger Library":

   -- a utility to create a new parallel modules from a set of well-tested templates

   -- a Manager utility to see all running Modules

Multiple Examples are included.  Of particular interest are:

   -- An example developed over a series of YouTube videos (linked below)

   -- A redo of the standard "Continuous Measurement and Logging" Example using Messenger Library

   -- TCP Reconnecting Example, showing easy network communication with handling of temporary disconnects

YouTube Instructional Videos: https://www.youtube.com/playlist?list=PL5AulxutFbdjFzxb-Lr6HItKR_2sG2aFA

LabVIEW Wiki: https://labviewwiki.org/wiki/Messenger_Library

Note: Messenger Library is intended to promote actor-oriented design, but is not related to the Actor Framework.

[drjdpowell]

In the past I have had problems communicating the key concepts of Messenger Library is as it is both:

• A library of communication that is a significant increase in capability over what we normally see in LabVIEW (thus the focus on Messaging Patterns above).
• an actor-oriented application development "Framework" in the same vein of DQMH or Actor Framework.

It seems that this dual focus losses people; those interested in frameworks think it isn't a framework; those not interested in frameworks ignore it as yet-another-framework.  I also have the problem of mentioning "actor" and losing people because they think this is an Actor-Framework extension.

Another problem I have is the depth of messaging patterns: this can be overwhelming to the new user and be interpreted as complexity (rather than well-filled toolkit).  Other frameworks, with limited tool sets, seem simpler (and are, until one finds oneself using your screwdriver as a hammer).

The "DEV Template" which is my standard module/actor design also seems complex at first look.  I could add far-simpler looking templates as well.  The problem is that all the DEV parts exist for good reasons, and I know a new User is better off learning the DEV than using a simpler design.

I have a "JKI Statemachine" template (not currently in the VIPM package) that I could include; would that help?  I could even include a "Producer-Consumer" version (like DQMH uses) but design is the biggest anti-pattern inflicted on poor new LabVIEW programmers and I refuse to be a party to that.

[Taggart]

I looked very briefly at it before and I have seen a few of your presentations and I liked what I saw.

I will try to find some time to take a look. My initial impression is that pallette is a little overwhelming. There's a lot going on there.

I would suggest a couple things.

1. Merge VIs (place subvi contents) are awesome! If you have a handful of VIs that are always used together, create a merge vi to just drop them all at once.

2. Create an advanced pallete, move a lot of those VIs into the advanced palettes (you still want them in the pallettes so that people can use quickdrop, but hide them).

3. You should talk to my buddy Llewellyn Falco. He's not a LabVIEW programmer and he is really good at making intuitive APIs. He helped me a lot with the approval tests.

[drjdpowell]

---

@Taggart wrote:

My initial impression is that pallette is a little overwhelming. There's a lot going on there.

---

Thanks.  I have taken this as motivation to do an extensive rework of the palettes.  Here is what it looks like now:

I've tried to "More" to indicate folders with extra tools, rather than required API.  And I hope I have reduced the amount of overwhelming terminology.  I have also pulled the methods for periodic timing (which are so valuable) into their own folder.  Using the actor templates, one should only need to use the top two rows on the palette (except for "Launch Actor" which I might have to add somewhere).  

[drjdpowell]

---

@Taggart wrote:

1. Merge VIs (place subvi contents) are awesome! If you have a handful of VIs that are always used together, create a merge vi to just drop them all at once.

---

Sadly, this suggests Messenger Library comes across as way more complicated than it actually is.  The most complicated bit of the API on the base palette is "Message Translation", which is optionally used just before "Send Message" or "Registration Message".  Otherwise, everything is generally one VI in one place.  If you look a teh "Continuous Acquisition and Logging" redone with Messenger Library example, the most complex use of the API is this:

I did use "place subvi contents" to good effect in "SQLite Library".

[Taggart]

---

@drjdpowell wrote:

---

@Taggart wrote:

1. Merge VIs (place subvi contents) are awesome! If you have a handful of VIs that are always used together, create a merge vi to just drop them all at once.

---

Sadly, this suggests Messenger Library comes across as way more complicated than it actually is.  The most complicated bit of the API on the base palette is "Message Translation", which is optionally used just before "Send Message" or "Registration Message".  Otherwise, everything is generally one VI in one place.  If you look a teh "Continuous Acquisition and Logging" redone with Messenger Library example, the most complex use of the API is this:

I did use "place subvi contents" to good effect in "SQLite Library

 Just looking at that snippet and having never really used the library I can understand what's going on, however that is only because of the comment. Without the comment, I'm not sure I would figure that out.

I'm not sure how you could make that easier to understand without a comment.

[drjdpowell]

Does the context help not help?