[sr-dev] Websocket module: Suggestions

Olle E. Johansson oej at edvina.net
Sun Mar 31 14:28:21 CEST 2013


30 mar 2013 kl. 21:33 skrev "Peter Dunkley" <peter.dunkley at crocodile-rcs.com>:

> 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


More information about the sr-dev mailing list