[Xprint] from inetd, how?

[Roland Mainz]

Ian Zimmerman wrote:
> 
> Hi, those who run up-to-date Debian know that Mozilla and Firefox don't
> have built-in PostScript printing enabled anymore (and other X programs
> will probably follow the same path sooner or later).  Instead, printing
> from Mozilla now requires the Xprint server.
> 
> But I only need to print quite rarely; in fact I don't even have a dead
> tree printer, all I want to do is occassionally "print to file", upload
> the output to my work machine and print it there the next day.  So
> running Xprint all the time seems quite wasteful, especially because it
> appears to be just a hacked copy of the regular X server,

Erm... Xprt isn't a "hack". Xprint is a X Consortium standard (see
xc/doc/specs/XPRINT/) and provides a fully-featured print API for X11
applications.
Why do you think it's a "hack" ?!

> the worst hog among daemons.

Xprt can help _saving_ memory since all resource-intensive stuff (fonts,
images, OpenGL textures etc.) isn't handled at the application side. The
resource usage which would happen within the application is MOVED to the
Xprint server side. You do NOT waste resources with that, you only MOVE
it. And if multiple applications or multiple users (think about large
multiuser systems) are using Xprt then even memory gets saved. LOTS of
memory (for the same reason things like "xfs" (X11 font server) were
invented...).
BTW: The same argumentation applies to "cupsd" or "lpd", they hog
memory, too.

> I'd like to set up Xprint to be started on demand through inetd.  The
> README.Debian file hints that it is possible but it doesn't give any
> specific advice or examples.  I could simply charge ahead but I am
> the worrying type, so these questions come to mind:
> 
> 1/ how does the client (Mozilla) know on which X display to contact
> the Xprint daemon?  It seems when Xprint is started the "official" way,
> from an initscript, the initscript sets up a file in /var/run or /tmp
> listing the available displays.  But if it's started on demand, that
> list obviously won't exist.

No, the specifiation defines that the Xprint clients find the Xprint
server using the XPSERVERLIST environment variable or via the
"XpServerList" resource. Running it via inetd would require that there
is a well-known port where Xprt sits...

> 2/ how does the Xprint daemon itself know it is being run through
> inetd, and so it should run the protocol on stdin/stdout rather than
> listen on a socket?  There's no _documented_ option to tell it so
> (the whole manpage for the daemon seems to be just a customized copy
> of the Xserver manpage).

AFAIK noone tried to run Xprt throught inetd yet. it isn't that easy
since the transport code needs to be changed to work with that. If I
remember it correctly Sun (either Alan or Jay) did some investigation
with Xprt+inetd but I don't know the results.
I see at least the following problems:
- Xprt enumerates all available print queues at startup - which may be
_SLOW_ in the case when there are remote printers which are OFFLINE. The
spooler may try to contact them and wait for an timeout. Xprt solves
that problem via caching the list and only updates them either on a
server reset or when the XpExtension API hook
- The XPSERVERLIST environment variable and the XpServerlist resource
must be distributed somehow... but how ?
- Multiple Xprint clients can share one surface (or better: "print
context") for printing (this is needed since an application may call
|fork()| to run the print process - and CDE's "dtpdm" uses that to have
the print dialog in a seperate process ("dtpdm" and "dtpdmd") which
prepares the "print context" and then passes it to the application). So
Xprt would need to be started in a way that multiple processes can reach
the same Xprt instance...

----

Bye,
Roland

P.S.: Just looking at the memory usage of Xprt: At startup it uses only
twice the memory of one "bash" session ("top" shows more but that are
memory mappings done via mmap() and no HEAP usage) - so running Xprt
only "on demand" doesn't save much (if you want to complain about
resource usage: "bash" consumes more than three times the memory of
"ksh93" - so why does Linux still use "bash" and not "ksh93" ? :)) ...

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)