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