> Okay, I'm obviously landing in the middle of a long discussion.
> Apologies if I'm covering old ground.
> What you describe is very, very sad. Anyone who's worked with
> lpr/lpd, and tried to deliver status or completion results has
> cursed this deficiency in lpr/lpd -- the completed job vanishes.
> Now here we are 25 years later, and we're propagating the same
> shortcoming.
This strikes a chord... Back in the mid 80s when the original Laserwriter first
made its appearance I was working for Harvey Mudd College. I was asked to
develop support for it on VMS. I quickly found the system-provided print
symboints (basically the same thing as lpd) were useless, so I wrote one of my
own (actually, I didn't write it from scratch, what I did was take code from a
couple of symbionts other people had written and create my own hybrid). The
result worked, but there were lots of complaints about error handling. So I
added a facility to report errors via email. This solved the problem.
Fast forward 15 years or so. I work for Sun now. Compaq has announced that
September is end of life for VAXes. VMS is on its way out too. And the
PostScript symbiont is showing its age big-time. It never worked quite right on
Alphas, for one thing. And at one point someone else hacked in network printer
support, but it ended up needing additional states that the data structures
didn't have room for. So it doesn't handle network problems correctly. And its
handling of Level 2 PostScript is, shall we say, lacking.
But we still use that old symbiont in some places. And one of the reasons for
this is those email notifications.
> Moreover, we're trying to patch the problem with
> machine-readable e-mail notification? If this is important (and
> it is), let's address the underlying problem.
> And please don't anyone tell me about their $99 printer for
> remote internet printing that can't cache a reasonable amount of
> completed job status but does have the resources to deliver
> multi-part MIME e-mail. ;-)
Another chord... Back in the old days when I first coded support for email
notifications in our product, I used a template. Later on, when MIME came out,
I simply modified the template to produce multipart MIME where previously only
single parts were producted. If memory serves, the only new code I needed to
make was something to add unique boundaries. The result was the template code
got a bit bigger and I added maybe 10 lines of new functionality. Then, when
NOTARY, with its structured report format came out, I changed the template
again to use it. I also needed a few more substitution operators, so this was
more costly in terms of new functionality -- maybe 100 lines or so.
Frankly, the bigger problem with this stuff is i18n support for the text.
But that's a different topic.
IMO the supposed difference between simple text and a structured report is a
chimera. Email support in general is another matter, of course.
Ned