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/blueroofmusichttp://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>