On 03/08/2010 03:58 PM, strasser@uni-bremen.de wrote:
Zitat von Andrey Semashev <andrey.semashev@gmail.com>:
On 03/08/2010 03:00 PM, strasser@uni-bremen.de 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:
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.