|
|
PurposeTo 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
High Level OverviewSolaris 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, the Hardware Abstraction Layer (HAL), commonly used on Linux, will be integrating into Solaris shortly. It will contain support for recognizing sysevent device add/remove events.Support for directly attached printers will come in two varieties. First, there is the hotplug 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 hotplug support should be recognized by HAL as it integrates into Solaris. Polling and network printer detection will require the addition of "addon" module(s). 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 message for the printer add/remove will be generated. This message may be received in the user's desktop session by the gnome-volume-manager, causing a desktop notification and potentially launching a print management application to handle the event. More Detailed InformationLocally attached Hotplug printersCurrently, hotplug events are generated
for "disk" and "network" interface devices. It appears that the
intention was to include "printer" and other device support.
6450793 printer hotplug events should be handled properly introduces private hotplug events for EC_dev_add/ESC_printer and EC_dev_remove/ESC_printer that will be generated for printers that are attached to and removed from the USB interface on a host. The hotplug events can supply the following HAL printer properties:
This interface will go through
architectural review and be made available for consumption by
applications through a contract. A contract for this will be
needed before HAL is made to recognize it.
Locally attached Polling for printersHAL provides an Addon mechanism that
allows plugin "daemons" to run within HAL and poll or search for device
add/remove events. Since ecpp interfaces don't support a hotplug
mechanism to determine if a printer has been attached, this project
will build an appropriate HAL Addon module to poll for newly attached
ecpp parallel printers. Because the ecpp driver allows the
retrieval of the IEEE 1284 device id string, this module can also
supply the following HAL printer properties:
Network attached Polling for printersSince there are a large number of
network attached printers in use today that don't have the capability
of announcing themselves to the network, A HAL Addon module will be
created that will be capable of broadcasting out either an ICMP Echo
request or an SNMP get operation on the network. Further attempts will
be made to interogate new printers for Manufacturer, Model, and Serial
number information, as well as a preferred means of communicating with
the device. The results of this detection and interogation will
cause associated HAL printer properties to be filled in as follows:
If this is not possible through a HAL
Addon module, it can be done as a seperate service that generates
appropriate D-BUS messages for the desktop monitoring agent to
subscribe to.
Network attached Hotplug (mDNS)More on this as mDNS support makes it's
way into Solaris, but the jist of it is that we want to be able to
detect printers that support mDNS as a means of advertising their
availability on the network. mDNS is the underlaying technology
used for Zeroconf on Linux and Bonjour/Rendezvous on MacOS/X.
With mDNS, network attached printers will announce their Make/Model
information, as well as their preferred method of communication.
Network attached Hotplug (SLPv2)Not at this time, but maybe later.
Network attached Hotplug (UPNP)Not at this time, maybe later.
Network attached print queues (CUPS Browse)inetd udp listening. This is
prototyped and will be made available for comment and testing
shortly. There is also a companion advertising service that goes
with it.
Network attached print queues (SMB/Network Neighborhood)In the Microsoft Windows printing
model, print client systems generate printer ready output and pass this
output to a print queue on the host were the printer is attached.
As a result, Solaris must treat these print queues as network attached
printers instead of remote print queues. Discovery (browsing) of
printers through this mechanism will be integrated into the add printer
management tool instead of via a separate service using
libsmbclient / smbclient
Network attached print queues (mDNS/Bonjour)More on this as mDNS support makes it's
way into Solaris, but the jist of it is that we want to be able to
detect printers that support mDNS as a means of advertising their
availability on the network. mDNS is the underlaying technology
used for Zeroconf on Linux and Bonjour/Rendezvous on MacOS/X.
With mDNS, network attached printers will announce their Make/Model
information, as well as their preferred method of communication.
Desktop IntegrationThe bulk of the discovery and
notification work will be happening within and around HAL and
D-BUS. As a result, the gnome-volume-manager will be receiving
printer add/remove events. It is believed to be capable of
launching an arbitrary application upon receipt of these events.
For initial prototyping work, it can be used to simply launch the
current printmgr application, however, this will need to prompt the
user for the root (privileged user) password to be able to complete the
work. We will need to spend some time identifying specific roles and
working on improving RBAC support within the print service and print
management tools as part of the deliverables of this project.
Add Printer Event HandlingPrinter add events will generally occur
when the system and/or detection services detects that a printer was
attached to the host (or network). Attaching a printer should attempt
to reattach the device to an existing queue if there was one or create
a new queue if one is needed. The creation of a new print queue
should be as automatic as possible, but will most likely require user
interaction to provide specific preferences and data.
Remove Printer Event HandlingPrinter removal events can be generated
for
We need to look into when to notify the
user that the printer is no longer attached and ask them if they want
to remove it's queue. If there are pending jobs, they will need
to be asked what to do with them (remove or move to an alternate queue).
|