I liked the implementation idea by pe1chl, it's llike doing a tail -f on the log.

/log print follow do={ 
     :put "$.dead $.id  $.nextid  $buffer $message $time $topics"
} where topics~container 

I liked the implementation idea by pe1chl, it's llike doing a tail -f on the log.

Agree. And, "tail -f" == "print follow" ... but there is no pipe | in RouterOS...

So, print supporting a "do=" go a long way, IMO...

Code: Select all

/log print follow do={ 
     :put "$.dead $.id  $.nextid  $buffer $message $time $topics"
} where topics~container 

{
:local killscript [:execute {/user print follow-only where [:foreach item in=[/user/active find] do={
   :if ([/user find name=[/user/active get $item]->"name" disabled] ) do={
     :do {/user/active request-logout $item} on-error={}}} ]}];
:delay 10s;
:do { /system script job remove $killscript } on-error={}
}

You can't press CTRL-C when it is still following and running in a script.

This still very granular and no event timestamps control avaiable and no .id to know which setting has exactly been changed.

And I don't say in any way that this the solution, but this is something that we can now work with. My original proposal is allowing much more control over what exactly is happening and react precise to that.

Perhaps when you hit a use cases like that it’s time boot up a linux based NOS: highly introspectable, debuggable and with an arsenal of mature programming languages.

For instance, I want to know if a port drops from 1000 to 100. I can poll though through a script routinely, but it would by much nicer to just have that logged change trigger a script. ie, this is something that happened to a port, and it was a speed change. make a script subscribed to 'ethernet ports' and 'speed change' and then only trigger that script when matched.

Monitor can see all interface speeds however I use that.

Code: Select all

@/interface ethernet print proplist=name,speed         
Flags: X - DISABLED, R - RUNNING; S - SLAVE
Columns: NAME, SPEED
 #    NAME          SPEED
 0 X  ether1             
 1 R  ether2             
 2 X  ether3             
 3 X  ether4             
 4 X  ether5             
 5 RS ether6             
 6  S ether7             
 7  S ether8             
 8 RS ether9             
 9 RS ether10            
10 R  sfp-sfpplus1  1Gbps

I can only see the speed of the SFP, only that one can be used for events through print follow-only.

having event driven scripts would allow us to also do this.

Am I the first one that discovered the potential of this bit of code that MT just left there to be discovered?

https://help.mikrotik.com/docs/display/ ... ive/listen
[...]
So for CLI, there could be improvements taken from the API. What about an interpreter giving CLI direct access to API. There is already a cross over and you will find proplist under print enabling to only show a specific value.

To me, MQTT is only polling and when you describe you still have to initiate a pol to retrieve data. I like a clean approach for ROS and that it pushes data on change, and not when a request is done.

The described model heavily reminds me of frontend web development.

Perhaps when you hit a use cases like that it’s time boot up a linux based NOS: highly introspectable, debuggable and with an arsenal of mature programming languages.

You're asking too much, for the most part we don't need this and if we did, having event driven scripts would allow us to also do this.

having event driven scripts would allow us to also do this.

It's for sure flexible, but raises a lot of question. E.g. given a series of related events, what is the proper order? If your action on an event leads to it being re-triggered, then what? If you have multiple actions on an event, how to determine execution order?

And are absolutely no debugging facilities, moreover a mistake (broken configuration or an indirect but indefinite CPU-consuming loop) will leave system inaccessible. And there won't be any post-mortem facilities either such as core dump.

Perhaps when you hit a use cases like that it’s time boot up a linux based NOS: highly introspectable, debuggable and with an arsenal of mature programming languages.

You're asking too much, for the most part we don't need this and if we did, having event driven scripts would allow us to also do this.

For instance, I want to know if a port drops from 1000 to 100. I can poll though through a script routinely, but it would by much nicer to just have that logged change trigger a script. ie, this is something that happened to a port, and it was a speed change. make a script subscribed to 'ethernet ports' and 'speed change' and then only trigger that script when matched.

/interface ethernet monitor [find where "ether2" !"1Gbps"] do={:log warning "Ether2 changed it's speed"}

Copying a successful model isn't a necessarily a bad approach.

Now things like "/ip address print follow as-value" should allow a do={} action to "monitor" a value... BUT it there is no do={} on print so CANNOT – unlike the API which has a "listen". But that be at least one "event driven" way of listening for changes from script, with minimal changes.

And, perhaps similarly if all "set" or "add" supported on-change={} attribute in config (perhaps others on-XXXX?) ... since that be more tied to the eventual "id" – just without a register step.

On your larger concept...
I've thought it be nice to "register" functions and listeners to "paths"... e.g. ideally update the data shown in /console/inspect to extend the "schema". And have that "schema extension scripts" as part of config...so you could essentially have a wrapper layer to do config using higher functions than the add/set primitives.

/ip hotspot user print follow-only where [$EventHandler Name=$name];