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

Subject: Re: [boost] [log] Boost.Log formal review
From: strasser_at_[hidden]
Date: 2010-03-08 07:58:31

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.

the reason I asked this question is because I think log records need  
to have (type) identity.
especially for (but not limited to) reading back log records, as was  
discussed when the review was announced.

>> - 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.

>> - 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.

my focus here was again WAL. WAL records consist entirely of  
attributes that are dumped in binary form.
I presume attributes are now stored in a  
std::map<std::string,Attribute> or similar. this is not an acceptable  
performance overhead for WAL.

>> - 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!";

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.

Regards,