Bill,
On Sep 17, 2014, at 4:05 PM, William A Wagner <wamwagner at comcast.net> wrote:
> Not to overly labor an issue, to accommodate case 1, should we mention that a Cloud Service can create a job by some means other than a Client-supplied Create Job. For example, if as you suggest, a Cloud FaxIn Service is to use a local Print service to provide hardcopy output, it could transfer the job to a Cloud Print Service. But the Cloud Print Service must create a Job so that it can be communicated to a local Print Service using the modeled interface.
I believe we have that covered by saying that the Cloud imaging service is a SM imaging service that supports the new operations in the the Cloud Imaging Model. I.e., you can do everything that a normal SM service can do plus this Cloud/Proxy stuff.
> In case 2, I don’t understand your comment. The user is submitting a Job request to a Cloud FaxOut Service. The Cloud FaxOut Service needs to get Hardcopy scanned. The Local service has no knowledge of the Job and there is no direct connection of the Local FaxOut Service with the Cloud (except through the Proxy). Unless of course, this is an invalid mode and the User can only initiate the Job from the Local FaxOut Service. In this case, because we have not provided any way for the Proxy to initiate a Job in the Cloud Service, as you suggest, there must be some other mechanism for the Local Service to communicate with the Cloud. Alternatively, we could use a parallel to the approach discussed above for FaxIn and suggest that the Cloud FaxOut Service could submit a request to a Cloud Scan Service which would relay that request to an associated Local Scan Service.
What I took from your case #2 was that the local service was delivering the fax to the Cloud, which is out of scope since it isn't using the Proxy interface.
*If* there was a Cloud FaxOut service that offered hardcopy fax for users with a local Scan device, that local Scan device would be connected to a Cloud Scan service that would be instructed to send the scanned document to the Cloud FaxOut service with a corresponding job and document ticket.
> This idea of communication among different service types is an orchestration issue and has not yet been addressed in SM.
Not called "orchestration", no. But we have long had the ability to direct the output of a job to another service - FaxIn, FaxOut, and Scan all support it.
> But that part would be internal to the Cloud Imaging System and is out of scope to the Cloud Model. Simply allowing a Cloud Service to create a Job from something in addition to a User Client CreateJob request would allow the Cloud Model to cover Cloud Services using capabilities in Local Services.
> Perhaps we can continue this discussion at next Monday’s conference call.
I still that that is out of scope since it follows the standard capabilities of existing SM services. Perhaps we can mention it in the intro and maybe even talk up some use cases that can be listed as out-of-scope?
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140918/a519d95c/attachment.html>
-------------- 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/cloud/attachments/20140918/a519d95c/attachment.p7s>