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.