Feel free to commit any changes you have to outbound. There should be one difference between the enabled in WebSocket and in outbound. WebSocket already had the ability to be enabled/disabled through an MI command so the enabled cfg variable there actually does enable/disable WebSocket, but the outbound enabled variable should definitely be read-only. Regards, Peter "Olle E. Johansson" <oej(a)edvina.net> wrote: > >30 mar 2013 kl. 21:33 skrev "Peter Dunkley" <peter.dunkley(a)crocodile-rcs.com>om>: > >> Done. I think. >> >> I don't have a system here to test WebSockets at the moment, but the >> changes looked pretty straight-forward and it all compiles OK :-) >> >> Can you take a look and tell me if it is what you were thinking? > >kamcmd> cfg.get websocket keepalive_timeout >180 >kamcmd> cfg.get websocket enabled >1 > > >kamcmd> cfg.list >websocket: keepalive_timeout >websocket: enabled > >kamcmd> cfg.help websocket keepalive_timeout >Time (in seconds) after which to send a keep-alive on idle WebSocket connections. >(parameter type is integer) >---------------------------------------------------- > >This should be useful in snmpstats. Thanks! I'll work on that soon. > >I have a similar patch with "outbound enabled" - ok to commit in your module? > >That will be easy to copy to other module, like app_* and dnssec ;-) > >Having this functionality helps apps using RPC as well as SNMPstats users. Siremis is one good example. Ovidiu's HTTP >framework is another. > >Database connections would be another good thing to be able to monitor with SNMP. I think we're on to something here. > >- Use a read-only config framework variable to declare a module loaded, initiated and working. >- Use other variables for settings that can be changeable during runtime (but not during processing of a single message, > which is a cool thing with the config framework). >- Use this for exposing (read-only) functionality like "database connected and working" > >- Use this for modparams that you allow to change during runtime. > >Since there is a read-only flag, I suspect this was part of the design. > >What does the rest of the development gang think? Is this something useful - to use the config framework to >tell other modules about the state of a module, not just configuration parameters? > >If we agree on this, we can add these flags to more modules as we go along. > >/O