On 03/01/2010 10:44 PM, Daniel Larimer wrote: [snip]
I do not mean to put my requirements on this if my requirements are "out of scope" or to insist that such a feature is necessary out of the box, only that a boost logging library should be flexible enough to support some means of iterating over records in a log file.
I see. That is indeed an interesting view on logging. I must say, I did not have this feature in mind while developing the library, but I think it should be doable. The library does not provide any tools to read log files, so depending on the format you choose to store logs in, you'll have to implement one. In terms of the library, this will be a log source. Depending on how you want it, you may either make it directly invoke the signal, or pass the read records through the library and then invoke the signal from a sink backend. In the latter case you get an additional opportunity of filtering and/or converting the record into another form (e.g. textual in order to store it in a human-readable file).
If your library assumes that ostream<< is defined for every type then making an assumption on boost::serialization to support such a feature would be a relatively minor addition.
Well, there is no such mandatory requirement. Rather, the type has to support formatting of some kind, if a text-oriented sink is used. In the most common case - yes, the formatting means putting it into a stream. For binary-related sinks there is no such requirement, and the term "consume" describes the process best. In your case, consuming may well involve Boost.Serialization, there are no changes in Boost.Log required to achieve that. Note however, that AFAIK, Boost.Serialization does not have a tool for portable binary serialization, which was the main reason I didn't bother with binary sinks myself.
One last consideration is that often there is a desire to separate logging into a separate process that can optionally "connect" to the logging core and possibly perform some additional filtering on the other side of a socket.
If syslog is sufficient, Boost.Log has the according sink out of box. And there are many syslog servers out there. If it's binary logging, then that should also be doable. Just write a sink backend that would send packets through the network or shared memory to another process. But in that case you'll also have to develop the server side (which, of course may use Boost.Log to process received records).
So my question is, how hard would it be to accomplish some of my requirements with the built in functions vs how much would I have to write from scratch to support it? I will look into it more, but perhaps someone more familiar with the package could offer an "estimate" in terms of hours required to implement some or all of the features I suggest. If they fit nicely into the framework, then I would likely contribute my own time to such an effort. If the framework starts to "get in the way" then perhaps we should consider the design.
Well, I can't estimate the hours, but these things will have to be made from scratch: 1. A binary logging backend. Depending on your needs, it may have to support portable encoding, network (Boost.ASIO will help here) or shared memory (Boost.Interprocess). You may take a look on how the syslog backend is implemented to get the idea of the amount of work. 2. A logging source that will receive or read the records. The amount of work here depends on what you want in particular, but the logic required by Boost.Log is quite trivial - call open_record and then push_record in the logging core. You can look at the basic_logger class to see what needs to be done. The rest is all the side work, like implementing serialization for your classes, setting up filters and sinks, arranging the signals you need, etc.