RPM version 4.5 versus 5.0

RPM version 4.5, both Elite and Select, were our longest selling products. In fact RPM Elite version 4.5 is the single best selling product in our history.

But, the 4.5 version was seriously showing its age. Version 4.0 was developed in the Windows NT era, and 4.5 consisted mainly of updates to 4.0. So, the company decided it was time to refresh our core products.

Version 5.0 is a complete rewrite. We looked at 4.5 to see how to do certain things, but beyond that, version 5.0 is all fresh thinking.

Our goals for RPM version 5.0

  • provide a modern, scalable product for current Windows platforms including XP, Vista, 2008 Server, etc
  • support older Windows platforms (2000 and 2003) to the best of our ability
  • address our clients' most serious difficulties with the 4.5 products, and answer the most frequent requests
  • make it easy for us to add features
  • incorporate best practices as advised by Microsoft and others
  • continue to provide a stable printing platform for our tens of thousands of clients who depend on RPM in their production print environments

Our most significant changes

Queue types versus actions and transforms. Starting with the original RPM, version 1.1, we offered 3 queue types: text, raw and filter. The way we processed your print job depended on the type; text queues used the Windows print driver to print, just like any other Windows application, including your desktop publishing system. Raw queues sent the data directly to the printer. Filter queues ran a program on your file. We also offered "print data options" so you could convert SCS to ASCII, remove PCL codes, insert a file, etc.

In the new RPM, we change this somewhat restrictive model to a new and completely flexible way of donig things. We offer around 40 transforms which you can order and configure any way you like. It is easy for us to add actions; the latest release has several new ones.

Once RPM has run your print job through all the actions you specify, we will then perform any number of actions on your print file [read more ...]

Print processing threads. The next major change is how we process your print jobs. Prior to version 5.0 RPM would pick a print job, then print it. When that job was done, it got the next and repeated. It was simple and reliable and millions of print jobs found their way through RPM versions 1.1 through 4.5.

The problem was that it did only one job at a time. If you had a very large print job, which happened to arrive before many small print jobs, the small jobs would wait until the large one was done. There was nothing you could do about it. We know; people tried. We have the calls and emails to prove it.

In the new RPM we have a scheduler which manages all the eligible print jobs. And, we have print tasks, which are waiting to print. The number of tasks are configurable for Elite; in Select you have two tasks ready at any time. The result is that the small jobs are not held up by the large jobs. It is very quick and people are very pleased.

Devices versus printers. In the old RPM we checked all the printers on startup. This could take a long time if the printer was shared by a computer you couldn't get to.

In the new RPM we treat all devices pretty much the same way. Printers, folders, and command lines (for programs) are all devices now. Devices are "reserved" when an action uses them to print a job. If the device is busy or in error, it won't be reserved, and the job will be attempted later with that device.

RPM also maintains a current use count, which is the number of print tasks using a device; and a maximum use count. You can set this to be whatever you want. This is how we know if a device is busy, if the current use count is the same as the maximum.

Devices also auto-recover. If they go into an error state, RPM automatically tests them every so often, and if the error recovers then the device becomes available and jobs are scheduled to it, all without "un-suspending the queue" or you doing anything at all.

Database versus registry. The old RPM used the Windows registry for all its configuration and job information. This worked reasonably well for a reasonable number of queues, but didn't scale very well for large numbers of queues or jobs.

The new RPM uses a stand alone database which performs well with the dozens of tasks reading and updating it constantly.