Re: Existing practice for embeddable IPP servers in printers

John,

> On Feb 9, 2026, at 2:04=E2=80=AFPM, John Scott <[email protected]> =
wrote:
> ...
> What's the current state of the art for a printer's internal software =
stack? Most OpenPrinting software doesn't appear to have been made with =
small microcontrollers (which may not have virtual memory) or real-time =
operating systems in mind, and I'm not sure it caters to this need =
anyway.

There are a number of generic printing stacks that are used on "low end" =
printers with different hardware/software requirements.  CUPS and PAPPL =
are also used on printers using embedded Linux and various real-time =
OS's with POSIX programming interfaces.  Otherwise you'll find that =
"well-established" vendors have developed their own software stacks.

> Many embedded operating systems that would make good candidates (Linux =
Foundation's Zephyr, Eclipse's ThreadX [1], or Apache's Mynewt or NuttX) =
are capable of running HTTP servers without fuss. It's conceivable that =
an IPP service could work by hooking into it with CGI or something like =
it.

Generic HTTP servers often don't support all of the HTTP functionality =
that IPP requires (HTTP Upgrade to TLS, chunking, transfer coding) but I =
do know of several implementations that have taken this approach, =
regardless of any limitations.

> Is that something that's usually done with custom code, or do =
lightweight libraries exist that help with processing jobs, parsing =
options, and the like? Is there any toolkit or library that helps in =
making small device-side IPP daemons, or is it something that isn't done =
with free software very often and there isn't much precedent for it?

For reference, CUPS' HTTP and IPP stack was developed on a 32-bit R2000A =
MIPS processor running at 25MHz with 8MB of RAM.  PAPPL-based printers =
exist that run on ARM-based MPUs/SoCs with half the =
capabilities/resources of a Raspberry Pi Zero W.

________________________
Michael Sweet