?~name=pattern~name~"pattern"
/interface/print
~name~"ether"/interface/print
?name=ether/interface/print
?name=ether1/ip/dhcp-server/lease/print
=count-only=
~active-address~"10.80."In terms of router CPU, yes. But overall, in order for the client to process a response, it needs to first receive it in memory (which is also spending some client CPU time right there, not to mention network bandwidth) which may not be good for the client, plus the actual regexp matching itself, which may not be as efficient as RouterOS' regexp.as it is, in most cases, cheaper for router to send packets than do regexp matching, API will not have this feature. And that has to be done on client side.
I couldnt agree more! We run routerOS on none mikrotik hardware - I think servers are capable of a little regex :/So although it would be more work for the router, it should be up to the user to decide where will they put the burden.
/ip address print where address~"10.10"Yeah that mismatch is weird. So I can put a "burden" on a router using SSH, but I cannot do the same using API? Where's the logic?But regex is available in scripting/SSH...
Unless the scripting/CLI engine is totally separate from the API engine and work totally different, I don't see how this augment makes any sense. The person that told you this "a long time ago" may have been right at the time, but it is clearly not an issue anymore.as i have been told some long time ago, as it is, in most cases, cheaper for router to send packets than do regexp matching, API will not have this feature. And that has to be done on client side.
Come on guys, don't play fool, do this API regex matching already. And when you decide to do it, don't use those crappy GNU Extended Regex syntax anymore, just go for the widespread PCRE-compatible syntax.Unless the scripting/CLI engine is totally separate from the API engine and work totally different, I don't see how this augment makes any sense. The person that told you this "a long time ago" may have been right at the time, but it is clearly not an issue anymore.as i have been told some long time ago, as it is, in most cases, cheaper for router to send packets than do regexp matching, API will not have this feature. And that has to be done on client side.
You are also assuming that the client is always more powerful than the router, which does not have to be true at all anymore. I think a RaspberryPi using the API would prefer the work being done on the router.
Anyway, would very much like for an update on this issue/request.
In fairness, they're already using POSIX regular expressions in scripting... Switching to PCRE is going to break a lot of scripts, and using PCRE just for the API while using POSIX for scripting is going to be confusing to people.And when you decide to do it, don't use those crappy GNU Extended Regex syntax anymore, just go for the widespread PCRE-compatible syntax.
Good points. I forgot about scripting and L7 matching. I hate POSIX regex, it's wrong on all fields. So let's vote for PCRE for RouterOS v7In fairness, they're already using POSIX regular expressions in scripting... Switching to PCRE is going to break a lot of scripts, and using PCRE just for the API while using POSIX for scripting is going to be confusing to people.
If the API uses POSIX regular expressions, that's enough IMHO. A switch to PCRE, if it happens at all, should be at v7, for both API and scripting.
Oh? Including this one?Please be patient, we will have some new features in ROSv7.
