[Openicc] Printing profiling targets - state of implementation?

[Michael Sweet]

Edmund,

On 2013-05-22, at 11:55 AM, edmund ronald <edmundronald at gmail.com> wrote:
> Is the idea bad because it would place additional burden on the CUPS maintainers, or is it bad for some architectural reason? 

It is bad from a security, a maintenance, and a forward-looking-architecture perspective.

Consider that we'd need to provide proper access controls, limits (don't want to use up all memory/disk with this data store), methods for enumerating resources that are available and a way to delete old resources (probably some of the WebDAV methods, none of which are currently supported by the CUPS HTTP stack), and all of the supporting security checks to make sure you aren't trying to store data someplace you are not supposed to.

And then are the resources per-printer, per-server, per-user?  Not a simple thing to add or maintain, all for just one project that wants it (Gutenprint) to support printer drivers that we are trying to eliminate (the future is IPP Everywhere).

A more likely future solution is that Gutenprint will become its own IPP Everywhere service (something that future CUPS will provide a framework for, so this isn't as big a deal as you might think), and at that point you can add whatever resource management solution you like, internal to Gutenprint.

> My reasoning is that if data cannot be passed via the options (too big) then it needs to be put in a file somewhere, if PPDs are going away then the PPD file is a bad place, and another file means a security headache etc, so why not squirrel the stuff away via CUPS.

Because you aren't getting rid of the security headache, you are making it incredibly larger by having a network-accessible server manager it, particularly one that does not support the HTTP methods needed to implement such an architecture.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20130522/26d235df/attachment.html>