I thought my desires for logging, maybe a graph were reasonable...then I saw
47 other flavors of output that were wanted...
Seems like your time might best be figuring out a way to design a pluggable
backend -- maybe a non-blocking subscription-host -- then a client program
could ask for regular data updates via "the connection"...
That way others could help write backends for stuff they wanted -- relieving
burden on you and providing freedom for them (hopefully a win-win)...
Same for allowing for data collections from other types of "monitor modules"
(or drivers) -- creating a pluggable interface could allow for people to write
monitors for hardware that might never otherwise be supported.
Just some thoughts... feel free to close or leave it open. I thought the idea
of local named-pipe or network-socket updates would provide safety for the
monitor (no linking in foreign code), while providing sufficient performance
for this type of app..?
Original issue reported on code.google.com by astara.a...@gmail.com on 25 Mar 2012 at 9:51
Original issue reported on code.google.com by
astara.a...@gmail.comon 25 Mar 2012 at 9:51