[IPP] New Cloud-related operations for IPP System Service

[IPP] New Cloud-related operations for IPP System Service

[IPP] New Cloud-related operations for IPP System Service

Ira McDonald blueroofmusic at gmail.com
Mon Dec 1 20:51:43 UTC 2014


Hi Mike,

Thanks - that all makes sense to me.

Oh - the other new operation for System Service should be
Get-Printer-Attributes that allows a simple "ipp" URI (w/out
any authentication?) that does a "magic" redirect to the default
print service, right?

BTW - what *is* the default print service?  The first one in
the list of configured-printers (services) that's of type print?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434


On Mon, Dec 1, 2014 at 10:58 AM, Michael Sweet <msweet at apple.com> wrote:

> Ira,
>
> On Nov 26, 2014, at 11:51 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
>
> Hi Mike,
>
> For operation (3) DeregisterOutputDevice, I was thinking of the case
> where a running service (Print in the near term) crashes (and this is
> noticed by System Service, let us hope).  If DeregisterOutputDevice
> is (redundantly) supported by the System Service, then an Administrator
> could do the cleanup for the Infrastructure Printer (who might queue
> jobs).
>
>
> Presumably DeregisterSystem is the way for the System service to clean up
> references to the output device in all services it manages, even those that
> have "crashed" (which is a state we don't really model semantically...) If
> you want to deregister from a single service, you talk to that one service.
>
> Or, I'm crazy, and the System Service would automatically do this
> cleanup internally and no external operation needs to be exposed.
> But that risks a Deregister when the crashed service can be
> successfully automatically restarted by the System Service after
> a brief interval of unavailability.
>
>
> I would assume that self-healing of this sort would be expected of a
> cloud/SDN solution, with notifications sent to the relevant admin/operator.
> And I don't think we can necessarily recover from all situations like this
> - the Proxy might well have gotten a response from its
> Deregister-Output-Device request, with the cloud service crashing after
> successfully sending a response, so we have to hope that implementations
> will provide a way to perform manual cleanup as needed...
>
> I have mixed feelings about the reliability (and advisability) of
> automatic recovery by the System Service for crashed or stalled
> Job Services.
>
>
> Typically servers will be restarted a certain number of times in order to
> provide continuous service, with an alert going out for each crash/failed
> restart. And such things are typically configurable by service and various
> events - I have such things setup with our PWG.org server instance, for
> example...
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20141201/d606b70c/attachment.html>


More information about the ipp mailing list