Am 21.05.2014 um 09:05 schrieb stepharo <[email protected]>: > >>>> >>>> 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! > >
