IPP Mail Archive: Re: IPP>NOT mailto feature from IETF meeti

Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM - TheIPPNotification I-Ds will now go the IESG)]

From: ned.freed@innosoft.com
Date: Fri Aug 18 2000 - 11:20:30 EDT

  • Next message: Jay Martin: "Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -TheIPPNotification I-Ds will now go the IESG)]"

    > 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



    This archive was generated by hypermail 2b29 : Fri Aug 18 2000 - 13:58:53 EDT