Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: printing at X terminals
Message-ID: <9007202239.AA24832@expire.lcs.mit.edu>
Date: 20 Jul 90 22:39:47 GMT
References: <9007171212.AA01273@smithkline.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 70


    >Since I haven't seen specifications for how vendors currently provide print
    >service, it's hard to argue.  But I think the real question is: can it
    >be made at least as simple, straightforward, and obvious, without going
    >through X.  It seems clear to me that it can be.

    It isn't as simple because the software for, say, lpr, is not easily
    available on different OS's and different network transport layers.

In this particular question I wasn't suggesting using lpr.  Use whatever
program you would use if you were using an X extension, but then just
don't use an X extension.  The code used by Xlib for different transports
is really not very large, and hardly unique.  Not at all difficult to
replicate.  Instead of calling XOpenDisplay, call OpenPrinter.  The
rest is identical (save for not using the X prefix :-).

    It's
    also not simple because the process of standardization is not being driven
    centrally, so the terminal manufacturers do what they want.

I wasn't clear, I was asking a technical question.  My fault.

    Viewed in a broader context than is generally appropriate
    on this list, X devices are local input/output devices.  It seems artificial
    to complicate their practical applications based on the concern that X is only
    for graphics (at least in this case :-)).

It is precisely the slipping into a broader context that we disagree on.

    This response frustrates me, because it doesn't show an appreciation for
    the practical problems encountered by terminal manufacturers and users
    who are trying to implement solutions on the fringes of the standards world
    (and standards don't imply availability anyway!).

And this response frustrates me, because it doesn't show an appreciation for
the practical problems encountered by a Director who is chartered with a
specific mission and who wants to avoid stepping in sinkholes and wants to
avoid moving into areas that others (e.g. formal standards bodies and other
industry bodies) will view as outside our scope.  These are "practical
problems" too, and cannot be dismissed lightly.

    The practical issues are important too.  X could provide a standard for local
    input/output.  An input/output extension for a simple byte-stream protocol
    is all that's needed.

I'm sure we could provide a standard, but the fact of that possibility
doesn't make it right.

    The only reason it was a bad idea was that local printing monopolized the
    connection.

No, I don't believe that's the reason.  It was a bad idea because it
fundamentally intertwined two things that were logically independent.

    Using this pipeline for input/output to local ports
    is an elegant solution which requires no additional transport mechanisms,
    and is analagous to using ethernet for differing types of network traffic.

We don't see the analogy the same way.  The way I look at your analogy, the
IP protocol (assuming it came first) would be required to contain subcode
space for any other transport protocol that you wanted to run on the same
wire.  Or the Telnet protocol (assuming it came first) would be required to
contain subcode space for NFS and X.  The ethernet running into my workstation
contains multiple, independent application-layer protocols.  The wire running
into my X terminal should be treated no differently.

    I propose a simple extension to X for input/output.

You are welcome to find a Consortium member to champion your cause,
and you are welcome to become a Consortium member and champion it yourself.