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 <stepharo@free.fr> 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"