Re: [boost] [log] Boost.Log formal review

Subject: Re: [boost] [log] Boost.Log formal review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-08 08:27:37

On 03/08/2010 03:58 PM, strasser_at_[hidden] wrote:
> Zitat von Andrey Semashev <andrey.semashev_at_[hidden]>:
>
>> On 03/08/2010 03:00 PM, strasser_at_[hidden] wrote:
>>> - not using user-defined log record types.
>>>
>> That exact syntax is not possible because the streaming expression is
>> executed after the record is constructed. Although the topic differs,
>> the reason is the same as described here:
>>
>> http://tinyurl.com/ydlncuv
>
> ok, but the issue there is not if the log record can have a user-defined
> type, but at what point the type and the attributes are specified so
> filtering can take place before the message is constructed.

As I said, the record now is constructed by the core, and it cannot 
construct a record of a user-defined type. The record, among other 
things, also holds some book-keeping data that is used by the library - 
the result of filtering in order to be able to feed the record to the 
sinks willing to accept it.

> the reason I asked this question is because I think log records need to
> have (type) identity.

I'm still not sure I understand. What kind of identity do you mean and 
what purpose would it serve?

> especially for (but not limited to) reading back log records, as was
> discussed when the review was announced.

Now that you mention it, I see the problem of constructing a valid 
record on the user's side. Yes, the problem is there, but I think it 
should not be difficult to solve it by separating the book-keeping data 
and the public data accessible from the record interface. However, I 
still don't see the need to create different record types on the user's 
side.

>>> - why is the logging core a singleton? should you not be able to set up
>>> multiple logging systems within an application, each with its own
>>> filters and sinks?
>>
>> 1. I don't see a use case for such a set up.
>
> you could think of setups that use multiple logging systems for regular
> activity logging, but for the use case of binary
> write-ahead-logging(WAL), which will be the focus of my review, it often
> is a requirement to maintain multiple independent logs in the same
> application.

The core doesn't limit the number of logs you can maintain. Just 
register as many sinks as you need and set up filtering accordingly.

>>> - for identifying attributes by runtime strings, instead of statically
>>> e.g. by attribute tags.
>>
>> Well, strings looked simpler and more natural matter for a key type in
>> attribute sets. A completely static solution is not viable because it
>> would require templating the whole library on the attribute set type,
>> which in turn would ruin modular architecture and increase compile
>> times dramatically.
>
> I think(!) it wouldn't require templating the whole library on the
> attribute set, but the filtering etc. could be instantiated on the
> attributes passed to the logger.

Attribute sets are used in loggers and the core. I don't see how it 
would be possible not to template them if some kind of type erasure is 
not used (which brings us to the current solution). Further, the core 
constructs a view of attribute values out of the attribute sets, which 
is basically a map, like attribute sets. This view is then processed by 
filters, formatters and sinks, so they will be templated, too.

> my focus here was again WAL. WAL records consist entirely of attributes
> that are dumped in binary form.

I guess, in terms of the library, these would be attribute values.

> I presume attributes are now stored in a std::map<std::string,Attribute>
> or similar. this is not an acceptable performance overhead for WAL.

And what is your suggestion? Use fusion::map? Or 
std::map<std::type_info, Attribute>?

>>> - special handling of message. why is it not a string attribute?
>>
>> Because the message string is composed after all attribute values are
>> acquired from the attributes. The link I gave above should give the
>> answer.
>
> ok, I might have mixed up terminology here. I meant the message on the
> user's part, passed e.g. by
>
> rec.message() = "Hello world!";

Yes, that's the message I was talking about. It is not an attribute 
value for the outlined reasons.

> I've asked before if binary logging is considered within the scope of
> the library. if it turns out that it's not, I can stop reviewing it from
> this angle at any time.

Yes, it has been considered. It is possible to create a binary sink that 
will serialize the attribute values and the message.