Well, I guess it depends on the number of entries. If you have 10 000 entries a database will certainly be an advantage. If it's just a configuration file that needs to be loaded once on program start, not sure...
And most important is the user interface that will come with it. If you first need to install third-party components to run external queries, then I would not like to see this feature implemented. Maybe I am traumatised by a report generating software I had to work with. They moved to a "cool" new db architecture. Now the same software (without adding much new functionality) lost the ability to deal with logs exceeding the 4GB limit of the free MS SQL edition. (That is the DB they force upon you. And if you need to deal with bigger logs, go ahead and buy an extra MS SQL server.) That new version has become much more demanding on the hardware (while monitoring or log generation are perfect tasks for less up-to-date equipment), and they "forgot" to integrate important DB maintenance functions, meaning that you can run your own queries but you have to install your own software to do so and you need to analyse the undocumented database structure first. I would not like SA to go that way :-) One advantage for a DB I can see though: if a check's configuration is re-read each time before it is run, then it would be possible to change something without having to stop and restart SA. (impact on the SA's small fingerprint?) Hope that explains my hesitations a bit, Rainer -----Original Message----- From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Dirk Bulinckx Sent: 9 avril 2011 01:32 To: Servers Alive Discussion List Subject: RE: [SA-list] What's next.... Well that's kind of weird, we get the request for a db so often and even on the list it comes back about once a year. People see the advantage in a db mostly in the reporting field and the updating of it. Doing a single change to multiple entries would even be easier with a db, as it would be a SQL update were you have a good "were" clause. Making a copy of the working config before doing these update would be done in the same way you would do a db backup (a sql dump for example). >From the app point of view it's easier/quicker to access each entry directly >(in the db) and make a change to it. That would make remote changes easier too. -----Original Message----- From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Rainer Jochim Sent: Saturday, April 09, 2011 12:01 AM To: Servers Alive Discussion List Subject: RE: [SA-list] What's next.... Nooooo, no database for the entries please :-) Well, there may be reasons to do so, but... sometimes a single change applies to multiple entries. The possibility to edit the text file and restart SA with the modified config is a big time saver. Of course it is also easy to destroy the configuration that way, but you would not do this without saving the working configuration somewhere first. What would you think of using some kind of CSV format, with a header row to better identify each single configuration entry and thus provide a more user-friendly text format? (or possibly an XML version, but CSV would be perfect) Thanks, Rainer -----Original Message----- From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Dirk Bulinckx Sent: 8 avril 2011 16:01 To: Servers Alive Discussion List Subject: [SA-list] What's next.... Often we get questions on what will be next in Servers Alive...so I'll give you a little round-up on things that are * almost 100% sure - SSH alert -> as alert execute an SSH command - Remote Icon -> that way you can get the tray icon of Servers Alive on a remote system (or on the local system when desktop interaction is not possible) - WMI based COM check * very sure - usage of a db instead of a textfile for the entries - extensions in the built-in webserver * maybe ... As always all feedback is welcome.... dirk To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list.
