Hi, I really do not get the tone of these replies, but perhaps my mail was not clear. So, let me start over.
You asked for who is interested in joining co-coding, and I said that I am interested particularly in the area of the logger. Specifically, I would be interested in splitting the Log class into two: - a Log class holding the current class side methods - a LogEvent (or LogEntry, or LogItem or whatever other name indicating the result of a single log statement) that holds the instance side of the current Log class. As it is now, when I execute: Log critical: 'message' I get an instance of Log. This is confusing, and not needed. We can nicely get an instance of LogEvent. This will not complicate things at all. Next, I said that as we already have a Zinc logging mechanism, I would be interested in consolidating Zinc to use the new mechanism. This would also provide a case study for having explicit classes of LogEvents and see the implications of that. And finally, I mentioned the Fuel serialization. My idea was to offer a cheap way to serialize a log into a file by serializing each log entry as a fuel object, but I did not know that we already have a JSON serialization. So, this is not that much of a priority anymore. I will propose code for the splitting. Doru On Wed, May 21, 2014 at 9:05 AM, stepharo <[email protected]> wrote: > > >>>> 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. > > > 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. > > > > 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. > > > - 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! > > > -- www.tudorgirba.com "Every thing has its own flow"
