Subject: PWG-ANNOUNCE> FW: [Printing-architecture] PAPI Source code on SourceForge

From: "McDonald, Ira" <[email-masked]>
Date: Sat, 7 Feb 2004 10:31:04 -0800

Hi folks,

New PAPI source code to go with Norm's recent update to PAPI spec.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: Norm Jacobs [mailto:[email-masked]]
Sent: Friday, February 06, 2004 4:18 PM
To: [email-masked];
[email-masked];
[email-masked]
Subject: [Printing-architecture] PAPI Source code on SourceForge

FWIW

I have imported a bunch of PAPI source code into CVS on SourceForge
under
the "openprinting" project.  You can get to the SourceForge openprinting
project page via http://sourceforge.net/projects/openprinting
from there you can browse the CVS repository and/or get complete 
instructions on how to download code.

The short version is that
  $ cvs -d:pserver:[email-masked]:/cvsroot/openprinting
login 
  $ cvs -z3
-d:pserver:[email-masked]:/cvsroot/openprinting co papi
should get you a copy of code.

Since Shawn Pratt is the only listed project administrator for the
openprinting project on SourceForge and his email bounced, I have
initiated a "takeover" request for the project so that I can
administrate it (add administrators/developers/content/...).  In the
meantime, here are some specifics about what I have delivered.

I have dropped two PAPI library implementations and a client
implementation into CVS.

papi/papi-lib-dynamic
	This library implements all of the functions in v0.91 of the
	specification, but doesn't communicate with a particular backend
	print service or protocol.  It provides naming lookup support for
	printer configuration and dynamically redirects PAPI calls to the
	configured backend PAPI implementation.  The naming support uses
	the name service switch on Solaris and does a crude emulation of
	it on "other" platforms.  It also supports the use of URI style
	printer names (lpd://server/queue, ipp://server/printers/queue,
	etc.).  In the event that a URI is used, the uri scheme is used
	to dynamically load the backend PAPI implementation.  Without
	additional PAPI implementations installed, this module is of no
	real interest other than an example or skeleton to build a PAPI
	implementation from.  The papi-lib-dynamic code was contributed
	by Sun Microsystems, Inc.

papi/papi-lib-cups
	This library appears to implement v0.9 of the specification over
	libcups (mostly the IPP support in libcups).  It was originally
	written on top of libipp (an offshoot of libcups that IBM was
	working on).  I was unable to locate a copy of libipp, so I made
	a few modifications to the code to build under libcups.  I also
	fixed a couple of minor bugs and added some of the v0.91 interface
	calls to the code.  I have been able to use this module to
	communicate with a CUPS server as well as the IPP server Apache
	module that I have implemented on Solaris.  The papi-lib-cups code
	was contributed by by IBM.

papi/papi-clients-bsd-sysv
	This part of the tree implements support for the BSD and SYSV
end-user
	printing commands on top of the PAPI.  The implemented commands
	include lpr(1b), lpq(1b), lprm(1b), lpc(1M), lp(1), lpstat(1),
	cancel(1), accept(1M), reject(1M), enable(1M), disable(1M), and
	in.lpd(1M). The implementations are reasonably complete and should
	be pretty good examples of how to the the PAPI.  The in.lpd(1M)
	implementation is still missing some functionality.  The
	papi-clients-bsd-sysv code was contributed by Sun Microsystems, Inc.

All of the code uses Autoconf/Automake/Libtool to build.  You should
be able to build/install with:
	$ sh ./autogen.sh --prefix=/opt/papi
	$ make install
build and install a library first, then the clients.  I have
built/installed
on Solaris and Linux.  Things appear to be working, but I'm sure that
there are issues to be addressed.

We have an IPP listening service on top of the PAPI implemented as an
Apache module.  We are planning on dropping that code into CVS soon.
Also, we are finishing up a PAPI implementation on top of RFC-1179 that
doesn't require applications to have special privilege to use (mere
mortals can contact a remote RFC-1179 based print service via a reserved
port).  PAPI over IPP is in the plan and will likely use the IPP support
from the Apache IPP listener module, but we need to find an http library
to use first.

Anyway, I will send out another email when the SourceForge issue is
resolved.  I had hoped to get this all done yesterday afternoon, but
there are never enough hours in the day and there is an issue with
the CVS server right now, so the CVS repository wasn't available for
web browsing or anonymous pserver access until about 10 minutes ago.

		-Norm

_______________________________________________
Printing-architecture mailing list
[email-masked]
http://freestandards.org/mailman/listinfo/printing-architecture