Comparing NDPS with Queue-Based Print Services

The architecture of Novell legacy queue-based print services was based on the creation and linking of three components: printers, print queues, and print servers. Setting up queue-based printing was often a complex task. In order to print, users first had to capture the printer port. Then the client would redirect the data to a file in a print queue, where it was stored while waiting to be sent to a printer by the print server.

With NDPS, printer, print queue, and print server functions are combined into a single entity called a Printer Agent. The need to create print queues has been eliminated, and users send print jobs directly to printers.

Even though NDPS does not require queues, your networks might continue to include queue-based printers and clients not currently supported by NDPS. The backward compatibility of NDPS allows you to continue using these queue-based services and resources transparently, as is illustrated in the following scenarios:

You can print through NDPS to an existing queue, allowing you to access systems that require a queue connection (for example, mainframe systems using NetWare HostPrint^® and certain proprietary systems).

NDPS can service existing queues, allowing you to use NDPS on the server even though your client platform is not currently running NDPS. This allows you to install and run NDPS while you are changing your client workstations to NDPS.

For a discussion of NDPS support for legacy printing, see Supporting Queue-Based Client Workstations.

The following table summarizes the major differences between NDPS and queue-based printing services.

Queue-Based (Legacy) Print Services	Novell Distributed Print Services
Administrators create and link print queues, printers, and print servers, and users submit print jobs to the queues. These three objects must be maintained separately once the system is in place.	Administrators create Printer Agents, allowing users to submit print jobs directly to printers. All management functions are centered on the printer itself.
Uni-directional communications only. Feedback consists of pop-up windows reporting a nonconfigurable set of events.	Bi-directional communications supported. Configurable event notification includes e-mail, pop-up windows, event logs and other methods, including third-party methods such as beepers and faxes. Events reported are limited only by a printer's capability.
Does not accommodate add-ons or extensions from third parties.	Extensible framework for print devices, including snap-in interfaces.
Administrators must create and configure Printer objects manually. Plug-and-print public access printing not available.	Plug-and-print option available for installing public access printers using specially designed third-party gateways.