Re: [Printing-architecture] Google Summer of Code 2023 - Project ideas page for the Linux Foundation online

Michael Sweet <[email protected]> Mon, 16 Jan 2023 16:27:34 -0500
Newsgroups	dev.linux.lists.printing-architecture
Message-ID	<[email protected]>
Till,

> On Jan 16, 2023, at 3:06 PM, Till Kamppeter <[email protected]> wrote:
> 
> On 16/01/2023 16:17, Michael Sweet wrote:
>> Till,
>> FWIW, some of the PAPPL project ideas aren't a good fit for GSoC, particularly the IPP Everywhere 2.0 stuff (still in flux, and something I am already working on) and presets.  The scan stuff is "nice to have" but we are still a long ways away from having anything that can be merged and supported.
> 
> OpenPrinting project ideas on
> 
> https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects
> 
> Michael,
> 
> I was also in doubt about some ideas when I tried to create a description for them:
> 
> Update of OpenPrinting software to IPP Everywhere 2.0
> -----------------------------------------------------
> 
> - What are the exact differences between 1.1 and 2.0? Is it written somewhere to easily check?

The current draft of the 2.0 spec is at:

    https://www.pwg.org/ipp

The main changes are to make certain optional 1.1 things required in 2.0.  It will also depend on newer versions of several dependent specifications (PWG 5100.7 and 5100.13, in particular, have been updated since 1.1 and are in the final approval phase...)

> - Is 2.0 stable and complete enough for working towards it and is it also no subject of a quick replacement (by 2.1?)?

2.0 is marked as a prototype draft, which means it is ready for prototyping and is not expected to have significant technical changes.

WRT 2.1, we haven't even published 2.0 yet, but a 2.1 errata release MUST be backwards-compatible with 2.0 (conformance-wise) so I wouldn't worry about that.  Even 2.0 is just an incremental change from 1.1...

> Not like OAuth support where we decided on skipping working on its integration this year?

Um, I'm not aware of any such decision!  Certainly we haven't finalized things but our goal is to have IPP+OAuth prototyped this year (at least).

> - Is there actual coding work to do to achieve this?

PAPPL should already have everything covered, but I'll do a final pass after the 5100.7 and 5100.13 updates are final/approved.

> CPDB backend for IPP Infrastructure/Cloud printing
> --------------------------------------------------
> 
> Which software is the actual implementation of this standard and visible for the end user who wants to print from an application?

From the client side you are just printing to a different server.

> These two looked rather viable for me:
> 
> PAPPL Scanning support
> ----------------------
> 
> PAPPL scanning support was already planned and worked on in GSoC 2022, but one of the two contributors has failed, and therefore we did not complete it. Therefore I have opened one project idea for its completion. There is even already a candidate investigating on what needs to get done.
> 
> What do you mean with
> 
>    but we are still a long ways away from having anything that can be
>    merged and supported

I mean that the current work has laid the foundation but we haven't actually implemented everything needed to handle IPP and/or eSCL requests, route them through the scanner driver, get the scan data from the scanner, and feed it back to the client.

> ...
> Should I better snap AirSANE to make scanner drivers snappable (but it will be confusing for users if an MF device has 2 daemons, one for printing and one for scanning)?

Honestly that is the simplest way since ALL of the scanners we planned on supporting via PAPPL printer applications are already supported by SANE.

> PAPPL presets
> -------------
> 
> Is my idea in the feature request
> 
> https://github.com/michaelrsweet/pappl/issues/244
> 
> wrong? Or not implementable with current IPP? Or do you prefer to implement this by yourself.

Honestly I don't have a good feel for how/whether this should be implemented and added to PAPPL, and the only printer application that really needs this functionality is Gutenprint.  Probably better to focus on getting Gutenprint ported and supporting its presets, then we can look at how those presets will work with the existing PAPPL.

________________________
Michael Sweet
signature.asc (application/pgp-signature, 833 B)