Darren Kenny wrote:
> From the "making it simple" point of view - we are working on
> integrating the Apple Bonjour[1] stack into Solaris - using this, with
> suitable Bonjour enabled printers and with Bonjour integrated into
> the Solaris printer servers stack (it's very simple to add service
> advertisement to a service) we should be able to "discover" printers.
> Similarly we will be able to use this via the nsswitch mechanisms to
> enable use to retrofit discovery into unmodified clients - including
> printers. While CUPS is capable of using SLP to do some printer
> discovery, it has limited success [2].
>
> As for the printer features - if we couple this with IPP (be it Sun's
> implementation or CUPS) we should be able to have a scenario where a
> printer UI or CLI should be able to find printers and then discover
> the capabilities of each printer with relative ease. Tie this with a
> good UI to handle this (either in the GTK+ Printer work Glynn
> mentioned, or using a PAPI port of the libgnomecups libraries).
>
> To handle a new USB printer might be more cumbersome, but the
> integration of the HAL[3] in to Solaris, as part of the Tamarack
> work[4] we should be able to receive events when a USB printer is
> plugged in - this could feed into auto-configuring a printer (or at
> least providing the user with an option to configure via a "New
> Printer plugged in" type of wizard). With a decent UI here we could
> also make the printer addition quite painless (provided of course the
> user can get the PPD, or we can source it ourselves, Norm you might
> have some ideas here).
Ideally, I would like to see the addition of new printers be as
automatic as possible.
plugging in USB printers will generate a hot-plug event that can be used to
create a queue. Network attached printers and printers hooked up to
parallel
ports will require some type of monitoring and/or polling service to
generate
the events. That may not be the right thing to do in some environments and
exactly the right thing to do in others.
Once we know that we have a printer (that nobody else serves), there are
effectively
three cases that we run into
1) the printer already has a queue and you possibly need to
re-associate the queue with
the device. This should be able to be handled completely
transparently.
2) the printer has no queue and we can automatically determine and
match it's make/model
with backend support for the printer. This could also be
handled transparently, but we may
want to prompt the user for additional information (there is a
policy decision to be made here):
Basic:
Would they like to name the queue for the printer? (I
assume that we will
generate a default name)
Would they like to supply a description?
Will this be the default printer?
Would they like to share it?
Advanced:
Defaults for media(paper), duplexing(one-sided,
long-edge, short-edge), or
any PPD file capability.
3) the printer has no queue and we couldn't automatically determine
or match it's make/model
with backend support for the printer. This will require user
interaction to either locate and
install support for the printer or allow them to select support
already installed on their
system. It should additionally include the information prompted
for in case 2.
We also need to determine what action to take when a printer is
unplugged or we leave a network.
Maybe this should be asked when the queue is first created. If there
are pending jobs, should they
be removed, moved, or left alone? Should the queue be removed,
disabled, left alone, ...?
The current Solaris Print Manager (SPM) java GUI should probably be
updated to allow policy
decisions to be made and to include service level management (protocol
support, advertising, ...)
It definitely need to support more of the printer capabilities data as
well. I would like to see parts
of it broken out into their own components so that they can be used for
things like hot-plug
support and call-outs from elsewhere like the gnome-print manager. I
would also like to see
more refinements in queue management and better auto-detection/mapping
of printer-type to
it's support.
The current Gnome Print Manager (GPM) should make use of the underlaying
mechanisms to
provide use specific views of the available print queues. This should
include a mechanism for
updating the view. It would be nice if we could come up with a way to
figure out which printers
are most likely to be "close" as part of this.
>
> Glynn Foster wrote:
>>
>> I'd like to get to a stage where for the default user, everything
>> 'Just Works' [1] as much as humanly possible - although obviously
>> having a simple to use set of configuration dialogs to do more
>> complicated tasks.
>>
YES
>> I would personally advise us to already start looking at the new GTK+
>> printing stack, seeing what that gives us, and develop a printing
>> roadmap.
I have spent a limited amount of time looking at it and from an
application user's perspective, the GTK+ printing stack provides a print
panel that allows selection of a print queue to print on and selection
of it's capabilities.
-Norm
