On 16 Jun 2014, at 08:25, stepharo <[email protected]> wrote: > Hi sven > > Objects are the way to go.
Yes ! > Will this compatible be with SystemLogger? I mean could not you use > SystemLogger? I hope that SystemLogger can work with a subsystem that generates a stream of log objects, without requiring them to be subclasses of something. If so, then it will be compatible (just connect the announcer to where you want to sent the objects to). If not, then I don't understand how SystemLogger can be a pure object log. I said this before (and I miss this in the SystemLogger documentation, and even in the Beacon description): show real object based logging from the beginning, not degenerate string logging. In the case of SystemLogger, the class BasicLog already contains a message, why ? The API is also still mainly expressed with strings. (BTW, there should not be a messageText in exception, for example, being an instance of ZeroDivide or KeyNotFound with a key says it all). And like in the basic BeaconSignal, you predefine a timeStamp, why ? Is it really needed, or not ? In my other projects I don't use DateAndTime but ZTimestamp, things like that should not be forced on user. A timestamp even with high precision is not necessarily unique, that is why I added a secondary id. > Because I do not see them why I spend my time to build infrastructure. Sure, I need/want a nice backend with lots of functionality (like what Norbert was experimenting with). Also, for casual usage, some classes to inherit from are useful. Maybe a system level API as well. Second, we will probably need conventions, maybe expressed as traits of useful attributes for log objects so that we can write general analysis tools. > Stef > >> Hi, >> >> Since years, Zinc has been using its own Announcements-based logging >> mechanism for client and server logging. The payload of the Announcements >> used was still essentially text based though. >> >> In some discussions months ago with Norbert Hartl in the context of his work >> on SystemLogger, the concept of pure object logging as an alternative to >> text based logging became an interesting alternative for me. In an internal >> project that I did earlier this year I tried out this concept for myself and >> was quite happy with the result. >> >> Doru Girba had indicated several times to me that he was also interested in >> thinking about logging, so when he started talking about Beacon, I decided >> to write down my ideas a bit in a quick draft: >> >> https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md >> >> And to make this even clearer, I had to change Zinc logging to work along >> these principles. The current #bleedingEdge experimental/in-progress version >> of Zinc now contains a first working version of 'framework agnostic pure >> object logging'. The conversion is not yet finished - there is still much to >> learn here - but it already looks quite nice I think. >> >> Monitoring logging output can be done by opening an Announcement Spy. >> >> ZnNewLogEvent open. >> >> Next you run some code (start a server, do one request, stop the server). >> >> (ZnServer defaultOn: 1701) >> route: #server1; >> start. >> >> ZnClient new >> clientId: #client1; >> beOneShot; >> get: 'http://localhost:1701/random'. >> >> ZnServer stopDefault. >> >> Which give the following output (using the standard string representation). >> >> <Mail Attachment.png> >> >> However, each line is a rich object containing tons of information. Here is >> the highlighted line in the Explorer. >> >> <Mail Attachment.png> >> >> As you can see, all information from during the client and the server's >> execution is preserved, ready to be used for logging and/or debugging, right >> now or later on. >> >> Nowhere in the main ZnClient or ZnServer logging code is there simple string >> or text logging, everything being logged by announcing a log event object. >> >> I hope that this plays well with both SystemLogger, Beacon and maybe other >> logging frameworks out there. >> >> When I bring this approach more and more in production use, it will most >> probably evolve further. In the meantime, have a look: I would love feedback. >> >> Sven >> >
