Am 21.05.2014 um 09:05 schrieb stepharo <stepharo@free.fr>:
As a general matter, I would be interested in: - unifying with the ZnLogEvent
SystemLogger is infrastructure low level. So I do not see why Zn and SystemLogger should be unified.
yep
If this means talking to Sven this is a definite yes. I donât think we need to unify with the current ZnLogEvent. Syncing with zinc is probably not the way to go anyway. Zinc is still an external framework (hence the namespace prefix). I did a zinc bridge which operates an a single event bridging from zinc to SystemLogger. This is not clever performance wise. A better approach is to plug into zincs LogSupport. We should hook into there so we just get the invocations from zinc and we can emit the proper SystemLogger events into the Log framework. Sven will come up with something announcement based. And that is still a task for us, too. To look where functionality of SystemLogger is doubled with announcements.
We should pay attention that it stays small and simple.
It is and will be an extra anyway. You load zinc, you load SystemLogger, you load the glue code between them. Nothing to bloat the core.
first we should integrate it and make sure that all the Transcript show are funnelled to the Log frameworks.
Yes. Maybe we need to sync our understanding of log levels first. The exchange adds a log level and adding a tag would be good, too.
I do not get it but this is not a problem. No need to reply.
The Log as it is at the moment contains log level and a tag. Going from a simple logCr: you have to add a log level. Not everything will be debug/trace. With the tag I meant the tag of the Log class. This is a first-class citizen for categorizing and should be something like âimageâ or even better the name of the sub-system that emitted the message. Clear now? Norbert
- Split the Log class
we will not split it because we iterated over the design since 8 months with norbert :)
I cannot find the proposals of Doru. But Iâm interested. I splitted the Log class already into BasicLog and Log. Iâm not fully satisfied with it so ⦠My concern about the Log class is more how get it right supporting different kind of Log classes and still have a working filtering in the Logger. But that we can discuss in the groups that form I guess I would like to stop iterating. And again we should keep the system small. I studied all the logger framework available and I think that we can look for the graal forever or get done and I want to get done because there are other many many topics that can get fixed. Right now we went from 0% to 80% and this is a good ratio. We iterated with you. Now I do not want to pass time to go to an hypothetical 85%.
- Possibly support Fuel serialization for each log entry Please go ahead.
Yes. I donât even understand what it means :) Send code!