logging: also available separately

[zooko]

Everybody claims to dislike reinventing the wheel. However, sometimes it turns out that our new wheel design is way better than any of the existing wheels that we can use. So I don't mind improving on wheels, but I really don't like improving on wheels and then not sharing our improved wheel with other people, thus compelling them to reinvent it as well.

So the new logging scheme that Brian is designing should be distributed as a separately packaged module, with minimal dependencies (unless of course it's too much hassle to live without one of our friendly useful dependencies).

It would be fine with me if it were contributed to the package named "pyutil" (or to a newly created package named "allmyutil", or whatever). It's okay if acquiring the cool new logger means downloading a package that also contains other potentially-generally-stuff, but not if it requires downloading Tahoe.

[warner]

I'm planning to implement the logging as a part of Foolscap, since it interacts with eventual-sends and remote messages. Also, there will be a foolscap "remote log reader" port. And eventually I hope to implement Causeway-style causality-tracing, which is all very foolscap-dependent.

[zooko]

How does it interact with eventual-sends and remote messages?

[zooko]

The logging system we use now is deeply intertwined with foolscap, in so many ways that I can't even being to summarize it here. I continue to feel as I did at the beginning, that we should share our wheels, but there's no way to offer foolscap-logging without foolscap. Maybe the thing to do is to just to advertise foolscap as being "The Most Excellent Way To Do Logging In Your Network Python App (plus it comes with a remote object system too)". ;-)