Hi Glen,
Thanks for the comments.
My use of the word "contrived" may not be spot on, but I think we're trying to hard find a problem with a couple of these scenarios.
I don't think the industry will "move" to a virtual style of printing, I think "virtual" printing via some type of Cloud support will be be added to the domain of printing/imaging solutions.
Again, the "virtual" aspect of imaging I think is the real value-add of Cloud Imaging. The less the client has to know about printer details, locality, protocols, etc., the better. The destination "device" or "target" will still have some semantic meaning, but the semantic meaning of the destination will be very high-level and application based - and NOT reside within the realm of, say, the PWG Printing Semantic model.
I think we want to get away from users' having to care about complex printer driver dialogues and users' having to know what all these parameters mean. The application, combined with the "context" in which the client is dealing with the imaging application, should provide enough information for us (as vendors) to auto-configure/auto-select everything the user is trying to accomplish. I say that knowing that this is difficult, and will remain a "goal" and not necessarily a "mandatory requirement" of near-term solutions.
R.
On Apr 27, 2011, at 8:43 AM, Petrie, Glen wrote:
> Randy, great discussion ... see my comments below
>> -----Original Message-----
> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
> Randy Turner
> Sent: Tuesday, April 26, 2011 10:10 PM
> To: cloud at pwg.org> Subject: [Cloud] Analysis of Cloud Printing use-cases
>>> My summary analysis of the use-cases (so far) is that the bulk of these
> use-cases are not "compelling" enough to utilize cloud services. And
> one or more of these use-cases seem somewhat contrived. From my
> perspective, any time the client wants to print to local ("on the same
> network") printing services, Cloud printing is really not needed. There
> are too many ad-hoc/guest printing services that can achieve this
> functionality, and these methods are far less complex than erecting a
> cloud printing service to do this.
>> [gwp] I am not sure "contrived" is quite right but are they "compelling"
> is the real question. I believe the question depends on how the user
> general computer/computing scenario (use-case) changing over the long
> term. Will computing move to the virtual or will it stay local? I
> honestly believe that in the long run it will become virtual; there are
> simply too many advantages to having a virtual computing system and,
> thus, very thing will be a (cloud) service. Note, even in a virtual
> computing world it is likely individual users will have a printer and
> access to community printers!
>>> On the other hand, any time the printing destination is "remote" and
> somewhat "virtual" from the perspective of the client, this is where I
> think Cloud Printing shows the most value.
>>> [gwp] Agree, the question is what makes it "Cloud Printing". Is
> print-by-email equal to cloud print. Even HP states on their web pages
> that ePrint (print-by-email) is not the same as Google Cloud Print (GCP)
> (which is cloud print). I am forming a definition of cloud print but
> right now but I see the same key element as Randy; that is a cloud print
> solution must have cloud-based-client-print(imaging)-manager. This is
> what is different about HP and GCP. That is, GCP represents a Cloud
> Print system that communicates with HP ePrint where ePrint is the
> back-end of the Cloud Print solution which I believe is a great overall
> solution.
>>> For instance, in the "Doctor sends a prescription to a drug store for a
> patient" scenario, I would assume that the drug store has "registered" a
> destination with a cloud provider (the destination can be temporary or
> permanent), and the destination is just a name, it's a "virtual"
> printing destination. The Doctor is told (via email to his PDA) what the
> destination "virtual" name will be. The Doctor subsequently types up a
> prescription and sends it to the virtual destination. He doesn't really
> know if it's a printer, printer-to-fax gateway, or some other kind of
> device. The remote pharmacy has registered the necessary information
> with the Cloud Provider and the Doctor doesn't care (assuming there's a
> trust relationship between doctors and pharmacies in the Cloud).
>> [gwp] The prescription-to-a-drug-store may not be a real scenario;
> doctors and drug-stores do this entirely electronically; there is no
> print involved.
>> This type of Cloud "imaging" service (could be more than printing,
> probably would be, something like an imaging "pivot" service that pivots
> the source among a number of different virtual destinations, each
> destination being potentially a different type of imaging
> device...print-to-fax gateway, print-to-email gateway, traditional
> printer, etc.
>> [gwp] Pivots = Distribute? Very old and in wide use today' that is
> "print to multiple destination" where the destination may be email, pdf,
> print, fax, ....................................
>> The way I see Cloud Imaging, the more the "source" of an imaging job is
> isolated from the "destination" for the imaging job, the more value a
> Cloud Imaging Provider can offer. By "isolated", I mean that the client
> knows little or nothing about the destination of the print job (isolated
> in knowledge), and nothing about "where" the destination is (isolated
> "geographically")
>> [gwp] While this reinforces the definition the Cloud Print must have a
> cloud-based-client-print(imaging)-manager. I believe the user must know
> the destination; at least for physical print, fax or scan.
>> Years ago, Kinkos broached the idea of "Cloud Printing" by tying
> together all their geographic locations into a virtual printing network,
> and subscribers could send their complex print jobs into the Kinkos
> cloud, and Kinkos would deliver the complete, finished bundle to the
> Kinkos location closest to the zip code of the job submitter
> (subscriber). This is something similar to what I am thinking about,
> but the concept of Cloud Printing (especially an Cloud "Imaging"
> Provider) could go beyond Kinkos.
>> [gwp] I remember this solution. I think they were too early and you
> will see them bring it back.
>> To me, if the source and destination are on the same LAN, Cloud Printing
> becomes far less compelling, however, device discovery and IPP
> Everywhere become more compelling.
>> [gwp] Again, if the computing world moves (as it appears to be) to more
> virtual computing world, the line between LAN, WAN (to the user) blurs.
> I believe device discovery (LAN or WAN) are critical. Not so sure about
> IPP-Everywhere. For example, for HP's ePrint does any know or care how
> HP's email service sends print content to their printers; no! HP is the
> only one that has to know how and what is done. HP might begin directly
> supporting IPP Everywhere input to ePrint; but how they might or might
> not communicate with their printer is not so well defined (at least long
> term). Is there a reason for HP (or others) not to use IPP Everywhere,
> no! It is a standard, meets current needs, something to use and
> support.
>> I will try and add to the list of use-cases published thus far with a
> couple of more concrete scenarios to which I'm referring in the above
> text.
>>> Randy
>>>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.