Aleksey,
On 2013-04-18, at 12:14 AM, Aleksey Shlyapnikov <alekseys at google.com> wrote:
> ...
>>>> 2. CloudConnectionStateType: How about a "not configured" value - I believe
>> I made the same suggestion for the Privet protocol as well.
>> "Not configured" means device cannot talk to the server yet, in this
> case server does not know anything about the device. As soon as device
> connected to the server for the first time, its state for the server
> is either ONLINE or OFFLINE. So, since this information can be
> inferred from other signals, we think "not configured" does not add
> any value here
Except that the specification here is for a local discovery mechanism and for local printing that is dependent upon GCP for full functionality. Seems like some indication that the printer requires configuration might be useful (otherwise how else does the user know to configure it?)
>> 3. VendorState: While I understand wanting to have a human-readable string
>> here, it is equally-important to have something a computer can understand.
>> Consider UI that might show an alert for a warning from the printer - "low
>> ink" is something you probably want to just show and hide automatically,
>> while "out of ink" is something you want to interrupt the user for and give
>> them the option to cancel, restart, or continue the job. And this is
>> something you likely want control over on the client side since UI choices
>> may be different depending on the platform involved. Also, I would avoid
>> providing an example like "System error 404." unless you want to see a lot
>> of those impossible-to-decypher messages... :/
>> One can utilize VendorState.Item.StateType severity level for this
> purpose. ERROR states will be more prominent in the UI, possibly with
> interrupting question, like suggested.
I guess if you are OK with vendors making these decisions, go for it. However, without a keyword/enum describing the condition it will be impossible for the client to make a more informed decision about how to present this to the user, allow the user to filter/acknowledge specific conditions, etc. And FWIW the Printer MIB and IPP already expose keywords as well as human-readable strings.
> ...
> We believe that our state set is very close to your model, but, at the
> same time, our job state is designed to define a set of operations
> which can be applied to the job. See below for the DRAFT state
> rationale. Also, we thought about having CANCELED state, but have not
> figured out how CANCELED and ABORTED state are semantically different
> from the set of operations point of view, and decided that conflating
> all non-successful states into ABORTED matches our model well.
For the Semantic Model and IPP, we use "aborted" when the service aborts the job (unable to process successfully) and "canceled" when the job has been canceled by the user (either via a cancel operation or at the printer).
Semantically they are two different things: "aborted" means the job could not be processed successfully, "canceled" means a user did not want the job processed.
>>>> Also, your job state diagram seems to indicate that all jobs are initially
>> held?!? Held jobs in the Semantic Model are an "equal" state to "pending"
>> (your queued), and either can be the initial state of the job, as well as
>> going from pending to pending-held or vice-versa. See the bottom of page
>> 111 in RFC 2911 for an example of what we use for job states:
>> We believe DRAFT state is necessary in our model. DRAFT state
> signifies that job is created, but still needs more attributes
> assigned before being promoted to QUEUED: document is not uploaded yet
> (job can be created without the document), printer is not assigned
> (job can be created without being assigned to the particular device,
> thus there's no queue to put this job into yet), capabilities not set
> (document uploaded, but printing parameters are not set yet).
This may be difficult to map to/from the Semantic Model; generally speaking, a job may be pending or pending-held with the additional "job-incoming" state keyword. For a printer to represent your DRAFT state they must basically ignore the job state and just report DRAFT if job-incoming is set.
> HELD state indicates that job has all job related resources (document,
> device, capabilities etc.), but not user related resources (printing
> quota, for example). Quota might be granted to the user to release
> this job to the queue. All jobs pass HELD state in order to check
> these constraints.
OK, so in your case HELD is the Semantic Model equivalent to pending-held with the "job-waiting-for-review" or some other reason, but you have no notion of a user-initiated hold?
> ...
> We believe your concern is valid, but since the cloud service is
> responsible for job state transitions and the only states devices are
> allowed to transition job to are DONE and ABORTED, they are not
> exposed to this complexity.
So where does the client look to for job state? And if Privet is not going to support local job management and monitoring then why expose the printer locally in the first place?
I guess I'm just not clear on where Privet fits within the GCP architecture or how it will be used...
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.