> Yes. Consider and API of well established unix logging facility such as > syslog. > From application's point of view there is only one direction in > communication: it writes to syslog, and syslog then directs content > somewhere else (and where exactly is doesn't matters and not a concern > of application). > And its also thread safe, of course (but not at cost of having only > single way to do things). And apparently there is no API to read what > is just written (like #ensureCr, which implies reading the last > character from stream to check if it is cr). > > In this respect an old implementation was much nicer in a sense that > it could be replaced by different stream which responds to same > protocol.. > But now, Transcript is a class, and its much harder to replace it and > as to me it is too hardwired. > Maybe this is good for Cuis, but as to me, i consider Transcript as a > generic/default logging facility in smalltalk system. > I was planning to redirect Transcript to write to stdout when in > headless mode (and when VMs will provide stdio communication out of > the box).
Yes we are in sync on that. > But how i suppose to do it now? Hacking existing class? And then > again, what if someone wants to redirect transcript to socket (and its > easy to imagine where we may need that - suppose you working with > remote image and want to see its transcript). > So, hacking the same class again? Ok so how do we make progress? > P.S. i know that maybe a preferable way to do logging is through 'self > log:' protocol etc.. > but lets face reality: there are a tons of code in system which using > Transcript. And i don't think that we will abandon it in nearest > future. > So, lets just keep it and make it more nicer, but lets separate concerns.
