Hi, I think we are all pretty much on the same page with how we think logging has to be done. In any case, here is the code (one, 1, line of code) that connects ZnLogEvent with either SystemLogger or Beacon - provided I understood everything correctly. ZnLogEvent announcer when: ZnLogEvent do: [ :each | BasicLog message: each ] for: #systemLogger. ZnLogEvent announcer when: ZnLogEvent do: [ :each | WrapperSignal log: each ] for: #beacon. Now this is using a wrapper object, BasicLog and WrapperSignal respectively. It even seems to work without the wrapping as well. ZnLogEvent announcer when: ZnLogEvent do: [ :each | LogDispatcher current addLog: each ] for: #systemLogger. ZnLogEvent announcer when: ZnLogEvent do: [ :each | Beacon announce: each ] for: #beacon. Question is, is the wrapping needed ? For the implementation or for the user ? Right now, only a timestamp is added. As I indicated before, I don't think that even 'forcing' a particular timestamp is a good idea. Here is my reasoning. Log events arrive in a certain order and that order should be maintained. Making log events sortable could be nice to have, but it is not 100% necessary. The same goes for uniquely identifying log events, nice to have but not necessary. A timestamp might seem like a good idea for both properties, but it is not. Consider: (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: DateAndTime now ] ]) asSet. The set will contain only a couple of instances. And this is for the most precise timing that we currently have. It is also easy to think of alternatives for DateAndTime that some people might prefer: just Time, seconds, micro or milliseconds since a reference, ZTimestamp (which I use in other code), some class from Chronos, whatever. Features, abstraction, performance, precision, memory consumption are all different. But regardless of clock precision, I think an id is useful as a secondary sort or identity criterium, just in case. But again, I would not require it. On the other hand, we need common protocol. What about the following: each log event object should implement #timestamp, which has to return a Magnitude compatible object so that increasing values conform with the order of the events (but not necessarily vice versa). Sven