I would say no Dave. There are projects I have done where I have employed an MQTT like topic structure to a property other than topic to help identify a value. e.g. when storing mqtt values in context for later retrieval
I would suggest the goal is mainly to be consistent with MQTT topics style filters.
But that is the whole point of the topic (sic) - to compliment MQTT style topics in a switch node.
Dont get me wrong, I definitely think wildcard matching in the switch would be great addition (I am all for it, where do I sign up) but IMO it muddies the waters with regards MQTT (see my previous post). Someone doing a primarily MQTT solution (as the guy who raised this) rightly or wrongly expected the switch node to do MQTT style topic filtering.
In 8 years, this is the first time I'm aware of anyone raising it. Let's not make it sound like a major problem.
I'm not keen on adding such mqtt specific semantics to a non MQTT node where more generalisable solutions can be applied and a wider audience benefits. The mqtt wildcards are great for one specific solution. That doesn't justify in my mind adding them to the switch node that is used for way more than just routing mqtt messages.
Its not & I personally dont think that either ( dont shoot the messenger )
I understand your point but to play devils advocate (sorry) - its not really a reason not to add it either. It has a use, aligns with the whole topic concept and is additive (benefits those who would use it - others can ignore it).
Am I reading your statement correctly here if i paraphrase that as ...
"I'm not keen on adding such mqtt specific semantics to a non MQTT node where a well defined wildcard option could be added for wider audience benefit"
... or am i mis-reading you Nick?
If I read you right then perhaps we should close this thread off here and start a new discussion on "wildcard entry for the switch node" in a new thread?
(please note I am personally fine with a wildcard solution instead of MQTT filter)
I'd be happy with that. Though I think it should be * and ? where ? is 1 character and * is any number. I think this is the most common form of wildcards?
see Nick's original comment (post 31) about burden of choice being detrimental.
"What would Jony Ive do ?"
or just use multiple MQTT nodes - each for its relevant group of topics - ie use the wildcard in subscription as god (andysc ) intended. They can all share the same connection after all so it's no greater burden on the system.
āChoosing from larger assortments tends to increase choice difficulty and, consequently, can cause consumers to rely more on accessible justifications when making their choice,ā researchers report in their paper, published in the Journal of Consumer Research. āAs a result, we argue that choosing from a larger assortment should lead consumers to select options that are easier to justify.ā More choice leads to better choices - Futurity
I think you'll find that Nick's carefully informed but opinionated design is what has helped make Node-RED what it is over 8 years
and yes let's move it over.
PS I hope you don't think i was implying anything there - I certainly did not mean to dis anyone nor our beloved node-red (not my style). I simply hope we can all fairly agree and disagree on points of implementation now and again without offending anyone otherwise there is little point to discussion TBH.
)
