Jump to content

Should I change the stupid name of “Messenging"


Recommended Posts

I’m in the process of getting my “Messenging†package put on the LV Tools Network, and they have politely suggested (as others have) that shouldn’t it be named “messagingâ€, as “messenging†isn’t an actual word.   Yes it is a messaging library, but I want a more unique name.  Other similar packages use unique names that don’t directly suggest what they are, such as “Alohaâ€, or use longer descriptive names that shorten to acronyms, like “AMCâ€.  I also like the focus on the “Messenger†rather than the “Messageâ€; maybe I should call it Messenger?

 

What do you think?  Is the “Messenging†name annoying, and should I change it?  

Link to comment

What's in a name?  Turns out alot.  I have an Messenging like framework (it was made before Messenging was released), and it took me a long time to come up with a good name.  I do think Messenging isn't a good fit, for a few reasons, but it does reflect what the software does which is better than some names.

 

I'd say it should be changed, but I have no suggestions.  

Link to comment

Brainstorming...

 

SendMSG Library  (SendMSG.lvlib is my core library, and sending a message is the core function of the entire package)

Messenger Library

Messaging Library

Messengers

Couriers

Send Message Library

Send Message Toolkit

SendMSG Toolkit

 

first decide if it's a library, Framework or Toolkit (I would suggest it is a framework since you have to write custom messages)

 

IPC Message Framework/Library/Toolkit? (boring but descriptive  :P )

Graphein Framework/Library/Toolkit? (I like this one :D)

Tiezi Framework/Library/Toolkit?

K̄h̀awsar Framework/Library/Toolkit?

(and other non English transliterations of message)

 

The Doctors Message Framework/Library/Toolkit?  :rolleyes:

Powells Post Office Framework/Library/Toolkit?  :rolleyes:

 

Personally, I would stick with what you used to be happy with if it wasn't a typo.I fight with NI all the time about the tools network and you can say "no thanks, I'm happy as it is"!

Edited by ShaunR
Link to comment

What was the name you came up with for your framework?

I almost didn't want to say because I was worried it would be stolen before it could be released.  Still the likelihood of me being able to release it is small.  Still I trademark it "Glued Framework", (Global User Event Driven)

 

It is a user event driven framework, which is publisher subscriber based, where each actor subscribes to the user events that it needs.  The publishing of the user events are in a write once read many (WORM) style global.

post-6627-0-30157300-1420568834.png

Link to comment

first decide if it's a library, Framework or Toolkit (I would suggest it is a framework since you have to write custom messages)

 

I’m specifically avoiding “Framework†because it’s meant to be a toolkit that one can take only some elements and not others.  Of course, it is really the framework that I use for real-world applications, but it isn’t intended to be restrictive.   It also doesn’t require much in the way of OOP skills; I’ve never created a custom message class for an application, and my “Actor†classes are thin shells, with no private data, wrapped around single VIs.**  This is basically text-variant messaging between individual asynchronously-called VIs.

 

— James

 

**I’ve recently experimented with a non-class actor design which is just a VI template.  This has the advantage that the VI can be set non-reentrant, rather than shared reentrant, making debugging more straight forward.   But i haven’t been able to make such an actor avoid the issue of root-loop blocking, which is problematic.

Link to comment

*I’ve recently experimented with a non-class actor design which is just a VI template.  This has the advantage that the VI can be set non-reentrant, rather than shared reentrant, making debugging more straight forward.   But i haven’t been able to make such an actor avoid the issue of root-loop blocking, which is problematic.

I'm using non OO based actors and I don't know the issue you are talking about.  Are you you talking about when one actor will keep the application from closing?  A global shutdown command that is a high priority user event takes care of that for me.  One major reason I dislike the official Actor Framework is the reentrant-ness which forces you to other debugging techniques (setting break points in the VI saving, waiting for a clone to be made and stop, then being unable to remove that breakpoint while running)

 

I thought about just Glue but it has taken on a life of its own now, and there's no changing it.

Link to comment

I'm using non OO based actors and I don't know the issue you are talking about.  Are you you talking about when one actor will keep the application from closing?  A global shutdown command that is a high priority user event takes care of that for me.  One major reason I dislike the official Actor Framework is the reentrant-ness which forces you to other debugging techniques (setting break points in the VI saving, waiting for a clone to be made and stop, then being unable to remove that breakpoint while running)

 

I mean the “root loop†needed to do an asynchronous call that is blocked by the User having a menu open.  

 

I personally have had little problem debugging shared reentrant actors.  I just send them a message to show their front panel.  I can even then add probes and restart the program to observe the startup behavior, as the same clone is always reused.  No breakpoints needed.   But there is a learning curve to this, which I’d rather eliminate by making it possible to have non reentrant actors.

Link to comment

As someone who's always thinking about naming everything "correct" (and continuously failing to get the perfect name :unsure:), I think the name should describe what it does and 'is' in few words possible. ShaunRs suggestion to suffix the current name with "Framework/Library/Toolkit" feels more correct in my opinion. And that's because it just is a Framework/Library/Toolkit for Messenging... (You could go as far to say it is a Framework/Library/Toolkit for Messaging between parallel processes, so a Parallel Messaging Framework/Library/Toolkit...)

I would even say it like "I'm using the Messenging library". However if you choose to stick with the current name it will be fine too (a little bit awkward though). Here my votes to your brainstorming:
 

Brainstorming...
 
SendMSG Library  (SendMSG.lvlib is my core library, and sending a message is the core function of the entire package)
Messenger Library
Messaging Library
Messengers
Couriers
Send Message Library
Send Message Toolkit
SendMSG Toolkit

 

"Messaging Library" is number one on my list, since it is grammatically correct (at least I think it is :rolleyes:)

Link to comment
  • 2 weeks later...

Hey drjdpowell,

 

Now when I think of this the Messenger Library, I think of it as specifically a framework for passing messages(a design pattern) to asynchronously running code(Actors), and I think of things like ZeroMQ and WAMP.  This link to WAMP has diagrams that sorta show a portion of the Messenger Library operation:  http://wamp.ws/why/

 

Also some zeroMQ info.   http://zeromq.org/docs:the-ten-minute-talk

 

 

What about a name like EMQueue  (Event Messaging Queue)

 

also, I pm'd.

Edited by monzue
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.