Am 25.06.2006 um 11:30 schrieb Gustaf Neumann:
Well, i would not base the whole design decision on this fact, since also from the c-level one could call the tcl/xotcl log functions
Well, this is not the only reason (see below). I also believe it is cleaner to have C-code not dependent (if possible) to any Tcl code. By getting apropriate "hooks" into the log facility, one can handle just about any situation with relative ease being it just C or just Tcl or a combination. At the moment, the way of expanding the log facility is pretty inflexible. Currently you can overload internal log and flush calls only. If one module redefines those log calls, another module can junk its modifications by plugging into the same hook. Also, the "default" operation of the log-facility is from that point, entirely dependent on the overloading module. This is not very nice and the idea is to improve on that as well. I will however not change that behaviour as I do not really know wether somebody is using it or not. What I'd do is to change the default way of handling the log entries by adding a list of callbacks one can add and/or remote to/from. The callbacks themselves can be written in C or in Tcl similar to the filter callbacks we already use. This way, the current log processing (a call to write(2...) will be implemented as yet-another-callback so the entire beast will be completely generic. By addind more callbacks one will not influence/replace the default processing, rather expand it! I hope to get some code pretty soon and I will post diffs to the list. This will then be much easier to understand. Cheers Zoran
