I dont have any immediate plans for this, but it would be a nice little
project if someone wants to dip into the Hobbit code (hint!). You could
easily turn off saving the file-based status logs (there's a
hobbitserver.cfg setting for that), and a module for storing the status
logs in a DB would be fairly trivial to implement as a Hobbit worker
module hanging off the "stachg" (status change) channel. Apart from
that, there's a simple change to pick the status log from the DB when
viewing it, and that's all.
Ahhh the BB/Hobbit, "How about a DB backend question ;)"
I've always been amazed that BB and Hobbit could use a filesystem as a database and not kill a server much *sooner*. hobbits use of memory for bbvar/logs is a huge win . . . .
Ideally the backend for most, if not all, of the state/history information for events would be a database. Problem is, that introduces a dependency of the product (hobbit) an another tool (Database). This can very easily become a nightmare from a support/ integration point of view. Not to mention you raise the bar for entry level admins ability to 'tinker' with the product.
Unless the entire hobbit tool were re-architected to have DB back- end, I don't think it would be worth the overall effort for keeping the histlogs area small.
That's *not* to say it isn't a good idea or it *wouldn't* be a great coding project for someone.
But I think it would be a better use of resources and benefit more of the user community if hobbit could internally, archive and retrieve this data. The history data is *extremely* useful and having it around is a wonderful asset for problem history/determination.
Henrik, I was thinking along the lines of every month or so archive the histlogs into a single large file, or one file per host, and then introduce logic into the show history that could determine if it needed to expand the archive to get it.
scott