Attributes for Queues/Notifiers

[dan_u]

For Variants and Waveforms attributes are available. It would be a nice addition if Queues and Notifiers would support attributes as well.

For instance when publishing measurement data over queues/notifiers we could have the signal name, unit, calibration, and measurement properties stored in attributes. The consumers could access the relevant parameters by just reading the attributes.

Since these parameters usually don't change for each sample it doesn't make a lot of sense to add them to the data. Also, attributes can be added/deleted while the queue/notifier data type is fixed. So currently we need to store that additional information separated from the data.

It would be convenient if we could register an event for attribute changes. This is related to the idea here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Expand-Event-structure-functionality-Register-new-type...

[crossrulz]

Queues and Notifiers are for transporting data.  They do not contain data themselves.  In this case, I would say to just bundle the data into a cluster or variant before sending it through the queue.

[dan_u]

Yes, but I want to use them to transport data only, not a payload of properties which doesn't change for many samples.

[Intaris]

Queues and Notifiers are for transporting data.  They do not contain data themselves

Well yes, that's how it currently is.  Kind of.  This is why it requires ideas to suggest change.  But I'm not sure the suggestion wants to make a refnum carry data per se.

When working with Queues and Notifiers (And semaphores) we also have the option to investigate whether a queue has remaining elements and other status information of the queue / notifier.  This is done (presumably) by accessing a central notifier or queue refnum broker which does the handling.  Why not be able to extend this to add attributes for each refnum?  This way the queue or notifier itself does not change but we gain the ability to couple them with certain important pieces of context information with proper synchronisation between creation / destruction of the individual items.

[AristosQueue (NI)]

I intend to decline this idea. This would improperly pollute queues and notifiers with functionality they do not commonly need. That's bad API design for any API, but particularly bad for performance sensitive systems like the queues.

If you need this functionality, bundle your queue refnum into a cluster with a Data Value Reference and let the DVR hold onto the attributes of the queue. You'll be able to access the attributes without hanging the queue itself. Or put the queue refnum inside the DVR if you need accessing the attributes to also gate all operations on the queue itself. That's an individual architecture decision and yet another reason not to conflate the functionality. Even better, the DVR can carry around the specific attributes you need with specific types instead of the type-generic system used by variant attribures. If you do need type-generic, then put a variant inside that DVR.

[Darren]

Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Attributes-for-Queues-Notifiers/idc-p/3254085#M34378