Inside of Sun, we have been looking at and discussing some of this for a
while now and we have posted information about this in the OpenSolaris
Printing Community portal, but we wanted to open this up to a wider
audience and see if we can't garner more interest and participation. As
a result, I am proposing the creation of a new OpenSolaris Project to
address the ease and automation of printing related configuration
management. Below is a brief description of what we are looking to
address. Obviously, this is open to change based on input and
participation, but It's a place to start.
-Norm
Purpose
To improve Solaris approachability, specifically the print service, by
automatically (or as automatically as possible) discovering and
configuring access to directly attached, network attached, and remotely
served printers.
Key Goals
* Provide users with a more hands-off/automatic mechanism for using
printers that they plug into their host or local network.
* Provide a mechanism for automatically recognizing and configuring
access to existing print queues as they move across networks.
* Use SMF for managing network queue discovery/advertising services
* Tighter desktop integration.
High Level Overview
Solaris includes a system event notification service that allows
applications to register and receive events that they are interested
in. As part of the Tamarack Project
<http://www.opensolaris.org/os/project/tamarack/>, the Hardware
Abstraction Layer <http://www.freedesktop.org/wiki/Software_2fhal>
(HAL), commonly used on Linux, has been integrated into Solaris. It
will contains support for recognizing sysevent device add/remove events.
Support for directly attached printers will come in two varieties.
First, there is the hot-plug variety where a device is plugged into an
interface or bus that is capable of detecting the event an propagating
it to the event notification service. This applies to USB attached
printers. Next, there is the traditional, polling variety where a
device is plugged into an interface that doesn't detect the printer
attachment/detachment, but instead requires the interface to be
periodically polled and then queried for information about the attached
device. This applies to ecpp (parallel) printer interfaces. Finally,
there are the polling variety that don't support a standard mechanism
for retrieving information about the attached device. This would
include centronics parallel printers and serially attached printers.
Devices attached through these interfaces are out of scope.
Support for for network attached printers will come from a variety of
sources. Many of the newer models of printers available today provide
support for advertising their availability on the network via protocols
like mDNS and SLPv2. When attached, these printers will broadcast (or
multicast) information about themselves to the local network. Some
newer printers and most older printers are not capable of announcing
themselves to the network. In order to detect their
attachment/detachment, a polling service must run somewhere on the local
network.
Support for finding available print queues on the network already exists
in Solaris in the form of network name service printer maps. These maps
publish a list of "advertised" print queues that client systems can
access. In a larger network with one or more dedicated administrators,
these maps are likely to be populated and reasonably current. In a
home, small office, or ad hoc network environment, these maps are very
unlikely to exist. As a result, a broadcast or multicast mechanism may
be a desirable alternative. Currently CUPS includes a broadcast print
queue advertisement capability that allows just such sharing. Windows
and MacOS/X also provide something similar. In order to provide maximal
interoperability, these mechanisms should be implemented instead of
inventing yet another mechanism.
Printers found through the system hot-plug support should be recognized
by HAL with some minor changes. Polling and network printer detection
will require the addition of "add-on" module(s) or separate services
that tie into HAL. Printer property probing will require the inclusion
of a printer probe program.
Once a printer has been "found" and probed or removed by HAL, a D-BUS
<http://www.freedesktop.org/wiki/Software_2fdbus> message for the
printer add/remove will be generated. This message may be received in
the user's desktop session by a monitoring application. This
application will then be able to notify user's of events and potentially
perform additional actions when those events occur. For example,
plugging in a USB printer may cause a print queue to be created
automatically, it may launch a pre-filled add printer dialog, it may
provide a notification, or some combination of these actions.
