All,
After reading through some of the email traffic over the holiday break, I'd like to outline some of my thoughts regarding how I think IPPSIX fits with the Semantic Model and how we should proceed with adding notifications to the Semantic Model.
1. Notification Service
I don't see how a first-class notification service makes sense. As implemented in IPP, notifications describe state changes to a Printer (service and its constituent devices/subunits), its Jobs, and its Documents.
In the Semantic Model, this would mean that all services could support notification operations (Create<service>ServiceSubscription, Create<service>JobSubscription, Renew<service>Subscription, Cancel<service>Subscription, Get<service>Notifications) and job ticket elements (Subscriptions group?) Naturally, services that are not job-based would not support job subscriptions.
If you wanted to monitor for service/device state changes across all services, you would talk to the System Control Service and send a CreateSystemServiceSubscription request with a list of events you are interested in. And then poll using GetSystemNotifications requests. Depending on the binding you could have GetSystemNotifications support the usual wait-for-events, maximum time to wait, etc. and also include a recommended polling interval in the response (just like IPP already does).
That just leaves how a Proxy might efficiently be notified when it has work - since the System Control Service isn't a job-based service and does not have visibility into the jobs of each service, it can't generate JobXxx events for the Proxy so it knows to ask a particular service for updates. The simplest solution is to just have the Proxy talk to each of the services it is registered with - GetPrintNotifications, GetScanNotifications, etc.
2. Devices and Subunits
Both IPP and the Semantic Model have a notion of devices (Output Device in IPP, Imaging Device in SM) with associated subunits (marker, input trays, output trays, etc.). Subunit state for all devices is reported through the corresponding attributes/elements, with a roll-up state in the printer-state-reasons attribute/StateReasons element. There is no way to associate subunit state with a particular device, although MOST services only have a single associated device.
For IPPSIX I added operations and attributes that allow a Client to query and a Proxy to supply/update the state of a particular device and its subunits. This is needed not only to support the existing fanout model in IPP and the Semantic Model, but to allow multiple Proxies to communicate with a single Infrastructure/Cloud service - otherwise a Proxy would always be responsible for state roll-up of all associated devices and subunits (right now it is an implementation choice).
One of the key concerns I've heard with this approach is that, in the Semantic Model, the subunit state is read-only and System Control Service is responsible for maintaining the state of all devices and subunits managed by the System Object. My response to this is:
1. Subunit state management and propagation is an implementation detail and not part of the model. Specifically, the Semantic Model does not define an interface between the services for coordination, etc.
2. Correlation of subunits with services and devices is likewise an implementation detail and not defined by the model.
3. The new operations manipulate separate sets of device attributes and not the read-only roll-up attributes reported by the Printer/Service.
Thus, I don't think we have a problem with extending the Semantic Model to support Get/Set<service>DeviceElements operations. The semantics of those operations can be well-defined and how a particular Imaging System does correlation and roll-up of the device elements/state can remain an implementation detail.
(conceptually we could add/expose DeviceId elements to each of the subunit status groups to formally correlate a subunit with a device; the inter-service interfaces would still be an implementation detail but it would make external correlation possible)
Thoughts?
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140106/1c488490/attachment.p7s>