Registering for actor 'callbacks'

[Synaesthete]

Crossing application/language/network barriers is basically my only concern, so I'm already dealing with some loose typing anyway.  Also, that definitely has occurred to me regarding the potential for run-time errors on the variant-to-data node.  However, I feel that if that's an issue, there's something amiss in the architecture.  It seems to me that a good architecture has sufficient "code context" that you can rest assured that you'll not get messages criss-crossing like this.

I'm experimenting with a concept I'm calling a "channel", which you treat almost exactly like queues, but which is actually an array- queue-of-queues.  A channel is an abstract class that consists of a DVR to an array of queues, allows for queues to be registered and unregistered, is capable of network broadcasts, and is strictly typed.  It has a single "broadcaster" and supports several "listeners", one for each queue.  The "controller" (usually the parent class) registers the broadcaster and all the listeners with that channel.  So the channel is only responsible for the data type of the message as well as all the callback registration, so really the listeners don't know a thing about the broadcaster at all-they just know they're listening on this channel and do their thing when they receive a message.

[David_Staab]

Synaesthete wrote:

1.)  Why does the LVOOP hierarchy matter?...If every message inherits from a common data message, does that cause any issues from either a performance or architectural perspective?

I can't provide any data to back this up, but I'm working in a 1400+ VI application with 100+ AF classes (actors and messages), and the LV compiler is having all kinds of problems: it regularly auto-mutates Bundle/Unbundle nodes when recompiling VIs to introduce logic errors, the object cache frequently gets corrupted and has to be flushed, and I've seen the "not enough memory to compile this VI" error more than once. The dev environment also likes to go out to lunch for 5-30 sec while crunching on minor edits. Having everything linked to everything else is, in my direct experience, causing serious issues with my productivity and the performance of LV itself.

2.)  Is there a reason to strictly define different message types and their intents?  Does this impact 'how' they are used architecturally, such that all "Event" messages inherit from a common "Event" message or are part of a common "Event handler", or is this designation arbitrary?  In other words, if there are Command, Status, and Data messages, are they called as such because they are different in their design, or only different in their usage?  Does making this distinction make it possible to capitalize on common routines or structures, or is it only a convention?

I know it'll take awhile, but read that thread I linked you to in my first reply. All of it, especially the responses by drjdpowell and Daklu with diagrams in them.

3.)  I think I'm in the camp of not understanding why something isn't truly zero-coupled.  It seems to me that if there's a lot going on in the generic classes that "breaks" that coupling, maybe there's something wrong with the architecture--you ought not to be messing around with generic classes once a framework and concept has matured.

The parent actor is directly coupled to the child actor, by merit of its incoming message class deriving from the child's outgoing message class. You can't insert a different type of child actor in the application without creating another derived message class in the parent actor.

4.)  Why is it necessary to have a recipient contain the enqueuer for the broadcaster and register for that broadcaster itself?  I'd imagine that you'd be adhering to more of a model-view-controller type architecture where a controller (typically the top-level parent) is responsible for making those connections happen, not something that occurs between broadcasters/listeners.

Ah, but who says your Broadcaster and Listener share the same parent actor? In my current application, a Temperature Broadcaster lives 3 and 4 links away in the "actor tree" from its two Listeners. Is the common ancestor of those three classes going to be responsible for registration? I prefer that it not, since I believe the great-grandparent of an actor should be pretty ignorant of what its great-grandchild is doing. (Yes, the GGP is ultimately coupled to the GGC as explained in my answer to #3 above, but it can still be highly abstracted from the GGC's specific command/status interface.)

[Synaesthete]

  Can't say I envy you.  I have already run in to some frustrations with just a couple actors regarding linkage issues.  I wonder about the continued validity of all the design time compiling being done.  In my current project, I don't intend to have any grandchildren--only direct children of a parent controller.  Actually I have ceased implementing complex architectures in LabVIEW altogether in favor of a polyglot approach--do only what I need to do in LabVIEW (DAQ, RT and some file IO), and do the rest in a more suitable language for large software architecture and user experience design (will never code a UI in LV again).  Huge breath of fresh air.

[David_Staab]

Props for use of "polyglot"!

(will never code a UI in LV again)

I get the impression that opinion is shared by a lot of people who attended last week's CLA Summit.

[Daklu]

2.)  Is there a reason to strictly define different message types and their intents?

Some people might get value out of strictly defining these message types.  I find it is sufficient to use descriptive message names.  (Verb-noun pairs for direct instructions, noun-verb pairs for event announcements.)

In other words, if there are Command, Status, and Data messages, are they called as such because they are different in their design, or only different in their usage?

The difference is entirely in their intended purpose.  There is no difference in their design or implementation.

Does making this distinction make it possible to capitalize on common routines or structures, or is it only a convention?

Neither.  It is (imo) a design principle that makes it easier to construct well-behaved and loosely coupled applications.

3.) I think I'm in the camp of not understanding why something isn't truly zero-coupled.

Coupling, in the abstract, is simply a measure of how much an arbitrary change in one component requires changes in the coupled component.  Any two components that collaborate are going to be coupled.  They may not have a static dependency (which is a strong form of coupling) but they need to agree on data schemas, division of responsibilities, etc.  The only way component A and component B can be zero coupled is by inserting another component--C--between them.  Then both A and B are coupled to C, but not to each other.  (Because any changes in A or B can be compensated for by making changes in C.)

I'm experimenting with a concept I'm calling a "channel"

I would call it a "dispatcher" or something like that instead of a "channel."  I think it more accurately conveys what it actually does.

So the channel is only responsible for the data type of the message as well as all the callback registration, so really the listeners don't know a thing about the broadcaster at all-they just do their thing when they receive a message.

How/where are you doing the initial callback registration?  Is that done as part of the sender's initialization code, or do you allow dynamic registration?  Assuming dynamic registration is a goal, how are you avoiding statically coupling the listener to the sender?

[bean123]

David_Staab wrote:

Props for use of "polyglot"!

(will never code a UI in LV again)

I get the impression that opinion is shared by a lot of people who attended last week's CLA Summit.

Off topic:

Could you elaborate more for those of us who were not attending?  Just curious.  For all the polygot's what are you using C#, Java?

I was hoping Xcontrols would eventually be very helpful with UI challenges in LabVIEW.  For example, I would like to create an abstact Multimeter Xcontrol.  Drop it into whatever VI I'm using and have all the implementation of the Parents/Children's code AND UI embedded in the Xcontrol.  Then just instansiate an instance of a child multimeter, pass a reference to itself (Xcontrol) around, execute methods, update propertires as necessary while having the Xcontrol update when its status changes. I've found ways to simulate this idea using subpanels but it adds additional layers to the code.  My limited understanding is

is that currently 1) Classes and Xcontrols that display their data should be decoupled or you run into a bunch of problems. and 2) you can't use an Xcontrol's reference as its datatype /data.

I'll be the first to admit I am by no means an Xpert in Xcontrols,Object oriented programming, or LVOOP, but it seems like UI development could be easier.   

[Synaesthete]

I've used XControls extensively in the past.  It's mentally very challenging and generally quite buggy due to all the crossing of run-time/design-time functionality, etc.  It strikes me as using a lot of concepts not meant for UI programming stuffed in to a UI programming paradigm.

The ideal polyglot scenario is to use a powerful lower-level programming language (C, or LabVIEW) with a higher-level scripting language (perhaps Ruby or JavaScript).

Personally, I combine C or LabVIEW with JavaScript.  Most of my application is a "WebApp" incorporating both server-side programming (MySQL and PHP, for example) with JavaScript and HTML5 for all my front-end UI development.  There are already droves of libraries with widgets for charts, graphs, buttons, sliders, thermometers, etc. that far exceeds the native LabVIEW UI library.  It's going to be tough for many programming languages to catch up to HTML5 in the near future for UI and UX, it's reached a striking level of maturity, power, and ease-of-use.. not to mention popularity and broad multi-platform compatibility.  I then let me LabVIEW actor engines communicate to the server or directly to the client over websockets or simple TCP/IP, sending simple strings or JSON as my data interchange format.

[Jed394]

This should be shared more b/c this is the future. I'm finding it harder and hard to justify using labview for anything other than the very backend hardware interface.  Even nodejs / python have come a long long way in hardware control.  The CRIO/FPGA high speed interfaces are really where labview shines.  They are falling behind everywhere else. 

Synaesthete wrote:

I've used XControls extensively in the past.  It's mentally very challenging and generally quite buggy due to all the crossing of run-time/design-time functionality, etc.  It strikes me as using a lot of concepts not meant for UI programming stuffed in to a UI programming paradigm.

The ideal polyglot scenario is to use a powerful lower-level programming language (C, or LabVIEW) with a higher-level scripting language (perhaps Ruby or JavaScript).

Personally, I combine C or LabVIEW with JavaScript.  Most of my application is a "WebApp" incorporating both server-side programming (MySQL and PHP, for example) with JavaScript and HTML5 for all my front-end UI development.  There are already droves of libraries with widgets for charts, graphs, buttons, sliders, thermometers, etc. that far exceeds the native LabVIEW UI library.  It's going to be tough for many programming languages to catch up to HTML5 in the near future for UI and UX, it's reached a striking level of maturity, power, and ease-of-use.. not to mention popularity and broad multi-platform compatibility.  I then let me LabVIEW actor engines communicate to the server or directly to the client over websockets or simple TCP/IP, sending simple strings or JSON as my data interchange format.