Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Michael S. <ms...@ms...>]

Robert,

> On Sep 23, 2021, at 7:54 AM, Robert Krawitz <rl...@al...> wrote:
>> ...
>> No, but having fixed limits does make memory usage *predictable*.
> 
> Well, other than that the underlying driver might not have such predictable memory usage.

Well, I can't do anything about the drivers themselves, just PAPPL. :)

> ...
> So I could have one set of options for the density settings and so forth, and I'm limited to 30 sets
> of options (or one set of options for each group of options, such as Basic Printer Options, Basic
> Color Options, Advanced Color Options 1, and so forth)?  Because that's not what it looked like.

The usual way is for one attribute = one value (or set of values).  Collections allow you to define more complex values.

>> ...
>> You already have a GTK+ UI, and modern web UI has similar capabilities.
> 
> I'd just as soon use the existing GTK+ UI rather than have to write a new web application.

Well, that is ultimately your call.

> Even a local TCP port (http or https://localhost) has its problems, since it means that something
> running under a different UID can access it.  A lot of browsers strongly discourage use of http
> these days, and https means getting a certificate.  Just a whole lot of hoops to jump through for
> what looks to me to be dubious benefit.

Well, again PAPPL handles all of this for you, and yes I understand that browsers have totally screwed things up WRT IoT device access - that is something I've been fighting for the last 10 years - but the standards call for web UI because that at least is portable.

>>> I'm not
>>> sure what a Gutenprint-specific web UI that allows people to tweak those knobs and create presets
>>> would mean, but that would seem to only increase complexity over having just one application.
>> 
>> I'm not sure I understand what you're saying?
> 
> I don't understand what the architecture would look like.  What exactly would this web UI do?

It is there to manage the printer(s) and job(s), print test pages, monitor supply levels, manage ICC color profiles and other resources, and configure defaults/media/etc.

> Where would the back end run?

The printer application *is* the back end.  This is not a cloud-based web server, this is a HTTP/HTTPS service that is hosted by the application courtesy of PAPPL.

> The printing application is a normal binary, presenting a UI.  A web
> application means a server somewhere.

It is NOT a "web application" that you would put up on a web server someplace.  It is an embedded web server running inside the printer application, and that EWS hosts a (simple) web-based user interface - think the CUPS web interface, but simpler.

> Why should there be a web UI in addition to the printing application UI?

Because people are going to be using printer applications as classic RIPs, to share printers with their family and co-workers, etc. And the only way to interact with the printer on the network is via IPP or HTTP/HTTPS.

>>> Where
>>> would the web UI back end run?
>> 
>> It is part of the printer application.  IPP runs over HTTP.  And a web interface is a required part
>> of AirPrint, Mopria, and IPP Everywhere.
> 
> It sounds like this would be separate from the main UI.\

It is a separate component of the same executable.

________________________
Michael Sweet