[Asterisk-Users] res_motv: Request for Comment

[Steven Critchfield]

I'm sure I haven't read all the relevant replies yet as I only completed
those who didn't break the thread.

My mindset would be to create a command line switch that returned the
int you mentioned that has the version details. This int could then be
fed to any app that could query your bugs database. This would help in
the automation of large deployments, or the integration with other
monitoring software.

The next step I would see is some form of SOAP call that could return
the data you mentioned. This allows a person who has collected the
version numbers for each of the machines they are running to then create
whatever monitor app they want in whatever language they feel happy
with.

As I see it fitting into my companies current monitoring schemes would
be a package is created at each of the deployed asterisk servers that
contained the version details. This package is routed however we have
configured it to reach a central repository. At this central repository,
we gather them all together and then issue our calls to your website
consolidating all the version numbers necessary into the least number of
calls out to you. We then filter on what is important for each of the
machines in question and register the update information with our
notification service. Then our notification service could notify those
who have registered interest in the machine, level, or event and be
notified appropriately. 

Of course, I would also wish to have the levels be augmented by the
subsystem as has been suggested elsewhere. I only care about Zap and IAX
channels,  core and agi apps. The rest are not interesting at this
moment. This could greatly reduce what I pull back from your servers and
reduce my tossing of records due to lack of interest.

Of course, I have described how it would fit into our monitoring
activity, I could also see a nice web front end built on top of the same
exact SOAP calls, and even run solely from the browser via the built in
Mozilla Javascript SOAP bindings.

The big point is build tools, not necessarily solutions. Tools can be
strung together for the solution, but it can also be broke down and
rebuilt easily enough from the outside.   
-- 
Steven Critchfield  <critch at basesys.com>