[3412] in SIPB bug reports
xrn kill files
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Thu Jan 7 10:40:50 1993
Date: Thu, 7 Jan 93 10:40:28 -0500
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: ckclark@mit.edu
Cc: jfc@Athena.MIT.EDU, bug-sipb@Athena.MIT.EDU
In-Reply-To: Calvin Clark's message of Wed, 6 Jan 93 19:40:32 -0500 <9301070040.AA17869@W20-575-106.MIT.EDU>
I was not the person who made the decision not to use the rn code for
doing KILL file parsing, so I can't say for sure why it wasn't ripped
out for use in xrn. I can, however, offer several possible answers:
1) Larry Wall apparently hadn't gotten a good hold on the "abstraction
barrier" concept when he wrote rn. Iether that, or he chose to throw
out abstraction barriers in order to make things quicker. The code is
not modular. It is extremely difficult to rip out portions of it.
Or, at least, that's what I've found. It's possible that the KILL
code is extractable; I haven't looked.
2) It's not obvious to me that all of the functionality that rn's KILL
code has should be in xrn. So, some of the code would have to be
disabled afterrr ripping out of rn. Furthermore, the KILL code is
dependent on lots of other rn code that would therefore have to be
included in xrn.
3) The current xrn KILL parser is trivially simple. I suspect it was
easier for whomever wrote it to write it from scratch than to go
digging in rn sources, so he just chose to do that.
4) He intended to later replace it with a better KILL file parser
(indeed, I believe there is an XXX comment in the code indicating
this), but put in a trivial parser to be improved later, and no one
got around to ever improving it.
If you feel like improving it, feel free.
jik
