richardvo...@gmail.com wrote: > Actually, I think you can avoid that without loss of generality. > > By DeMorgan's theorem, the AND and NOT operations currently available > are sufficient to define any expression. You just need a way to do > grouping, which a syntax for setting one tag conditionally based on > another tag would do. > > Remember that the example given doesn't need a complement applied, you > can negate it in the match later. > > Since "if" is a very well understood concept, I'd propose > > tag-if switch1,port1 newtag > > Where newtag gets set if all listed tags are matched. Using multiple > tag-if lines lets you effectively OR things together (this yields > sum-of-products capability). Allow a user to unset a tag with > > tag-if #switch1,port15 #newtag > > for even more flexibility, but now all tag-if commands need to be > processed in order. >
Genius! That's perfect. I think the second form might not be sensible, since the order of lines in the configuration file(s) is not significant anywhere else. The simplest scheme would ban tags defined in tag-if declarations from use in other tag-if declarations. If that wasn't done, there would be a need for multiple iterations to find all the tag values, and the possibility of unresolvable data-loops exemplified by tag-if black, white tag-if white, black I'd modify the syntax to match the changes in 2.53 where testing the value of a tag is always done with tag:<tagname> and setting a tag is always done with set:<tagname>, and ! is used for NOT. So we end up with tag-if set:newtag, tag:!switch1, tag:port15 I like. Back soon with a test implementation. Simon.