Norbert,

We are indeed all just discussing and exploring. On the other hand, Zinc has to 
work for real, on many Pharo versions and even on Gemstone.

On 17 Jun 2014, at 17:09, Norbert Hartl <[email protected]> wrote:

> Otherwise there will be three half baked approaches, one in zinc, one in GT* 
> tools and one in pharo.

What is currently in Zinc-HTTP-Logging is just a rich hierarchy of ZnLogEvent 
subclasses. ZnLogEvent does indeed hold onto its own announcer, pretty standard 
stuff I would say. Then there are two convenience methods #logToTranscript, 
which basically says

  self announcer when: self send: #crShow: to: Transcript 

and #open which opens an AnnouncementSpy. That's it. This gives me 99% of what 
I had before and a nice GUI tool as an extra.

There is a #logLevel property in ZnClient and ZnServer to control the volume of 
log events being generated because I am concerned about performance. We'll see 
about that.

> That would be the worst outcome. In order to prevent that I wanted to talk. 
> Just that!
> 
> My plan is to:
> 
> - look at beacon to see what Doru has in his mind. Maybe I get a good idea 
> from it
> - then I would look at Sven’s new code to see the difference to Doru’s and to 
> actual see if that works for more than a framework
> - finally I would like to look at the SystemLogger design again and improve 
> it where it might be improved. 
> - then there will be a new version of SystemLogger. That’s it. 

I'll send a separate mail on how easy it is, I think, to integrate ZnLogEvent 
with both SystemLogger and Beacon.

> I personally don’t plan to skip SystemLogger in favour of beacon or zinc log. 
> beacon is a proof of concept but there are AFAIK no formatters, outputs and 
> so on. So it is not even a replacement for SystemLogger. Zinc log is a log 
> system for a single framework called zinc. I’m not sure it can be useful for 
> anything else and I don’t think Sven is hitting in that direction.

No, of course not. Again, Zinc-HTTP-Logging is just a rich hierarchy of 
ZnLogEvent subclasses.

> I want a basic logging support that either has a central access for pain free 
> logging or it has multiple announcers (maybe one per module/framework) that 
> can be composed to a log source that can be attached to some kind of 
> dispatcher. I don’t know. That I need to figure out
> 
> Norbert

Sven


Reply via email to