Opinions please - delay - queue option

[dceejay]

so yes - at what point should a simple "delay/queue" node need to become a fully featured queuing node ? As ever I'm leaning towards trying to keep the "basic" core node simple enough to cover the default use cases and leave the full on capability to a (your) more dedicated queuing node - that may have additional outputs, and metadata, finer control, etc.

I think adding lifo/pushback would allow some level of failure recovery which would (to my mind) still make sense for the simple node.

[drmibell]

I don't think delay ever needs to become a full-featured queue. Adding msg.flush = N and LIFO features should cover the basic use cases without having to resort to a contributed node. I would try to distinguish between the two types of nodes in the sense that delay is time-based and and queuing nodes are command-based. (Obviously, flush and time-to-live are exceptions.) Trying to combine too many features of both types in a single node is likely to cause logic issues in development and confusion for the user.

If new use cases appear that are not met by either delay or queue-gate, we can discuss where best to address them. Meanwhile, I will re-visit @Colin's guaranteed delivery requirement to see where queue-gate fell down and whether something can be done for it.

[Colin]

@drmibell

I will re-visit @Colin's guaranteed delivery requirement to see where queue-gate fell down and whether something can be done for it.

I don't think there is much that can be done about it, the problem arises from the race conditions that arise when using multiple nodes to achieve the logic required rather than putting the whole thing in a 99 line function node.