I don't think anyone suggesting presupposing the requirements and dreaming up
scenarios to match...
I think we started out doing the right thing, gathering compelling use-cases and then distilling requirements (possibly overlapping) from these
use-cases.
I was trying to emphasize two points:
1. We need more compelling use-cases
and
2. IPP Everywhere is, at the end of the day, a protocol -- In my opinion, Cloud Imaging is a "business"
R.
On Apr 27, 2011, at 8:27 PM, William Wagner wrote:
> Randy, I think we all agree with your observation that not all use cases
> necessary should be addressed, and that the use cases from which
> requirements are derived, if not compelling in themselves, should highlight
> what we expect to be the compelling requirements that we need to address.
> However, the IPP Everywhere spec does need use cases as well as the Cloud
> spec. And there are some areas where either approach might be used, with
> perhaps just a slight twist in circumstances changing whether Cloud or IPP
> Everywhere is preferable.
>> Yes, there is work in sorting out the use cases, and a session at the May
> face to face has been allotted for that task. I suspect the thinking is that
> this is constructive work, and that a boarder view and differentiation of
> scenarios will give better insight into the requirements of each effort. At
> any rate, I suggest that this is an interesting alternative to the approach
> of presupposing the requirements and then dreaming up some possibly
> plausible scenario that illustrates the need.
>> Thanks,
> Bill Wagner
>> -----Original Message-----
> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
> Randy Turner
> Sent: Wednesday, April 27, 2011 9:55 PM
> To: cloud at pwg.org> Subject: Re: [Cloud] Analysis of Cloud Printing use-cases
>>> I wouldn't have aggregated the Cloud use-case set with IPP Everywhere -- it
> will just create work for someone to sort all
> this out because these services exist at different levels of abstraction.
> IPP Everywhere (the protocol) could be used to solve part of the Cloud
> Printing problem space, but it's a tool not a "service".
>> Also, please keep in mind when thinking about use-cases, there's an old
> marketing rule that says "Just because you can construct a use-case, doesn't
> mean you should support it" -- or to paraphase, "Just because you can
> construct a use-case, doesn't mean you should"
>> The use-cases that will "sell" this concept of Cloud Printing/Imaging need
> to be compelling and solve a clear and useful scenario. We should NOT
> market a Cloud Printing solution based on fringe use-cases. I believe the
> Pareto Principle (the 80/20 rule) applies here. 80% of the value of a Cloud
> Printing/Imaging Service will come from 20% of the use-case features.
>> It's like the iPhone -- the device has tons of features but it is successful
> because most people only use a handful of the capabilities of the device, at
> best. And Apple put the lion's share of their design and engineering into
> these few features. And they did it very well.
>> The features/use-cases for Cloud Printing/Imaging need to be obvious,
> compelling, and of high-value. It may help to start with a short
> description of a business plan for a Cloud Service and figure out what the
> take-rate (or popularity) of the service might be -- and obviously if it
> makes money. Then work backward from the plan to envision the details of
> how the service would work.
>> I think we need just three or four high-value types of service use-cases,
> and these use-cases can be distilled down to the key technology and
> capabilities that a Cloud Service should provide.
>> Randy
>>>> On Apr 27, 2011, at 10:53 AM, William Wagner wrote:
>>> I think we largely agree with Randy, and it was understood that the use
>> cases submitted were to be considered for Cloud and/or IPP Everywhere
>> applicability, since we needed use cases for each.
>>>> There are several circumstances however where printing to a local printer
>> might still best use Cloud Printing. One is where the client is using
> Cloud
>> Computing services. Although the real use case of QuickBooks check
> printing
>> did not involve a Cloud based service, one could conceive of a situation
>> (and the user in this case is considering it) where it might. In that
> case,
>> it would be the Cloud based service that is the client, acting on behalf
> of
>> the end user. Or the cloud based service somehow relays the print file to
>> the user, who then sends it to the printer; but with this alternate
>> approach, how does the service know the printer characteristics to format
>> the job...?)
>>>> Another case where cloud printing would be necessary, even when the user
> and
>> printer are physically co-located, is where there is no ability for the
> user
>> to connect to the local network (or perhaps there is no local network).
>> There are various scenarios for that, including perhaps situations where
>> guest users are not allowed for security or regulatory purposes. Indeed,
>> this would be a network remote although physically local user. Several of
>> the submitted use cases could easily be cast into this mode.
>>>> Thanks,
>> Bill Wagner
>>>> -----Original Message-----
>> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
>> Randy Turner
>> Sent: Wednesday, April 27, 2011 1:10 AM
>> 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.
>>>> 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.
>>>> 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).
>>>> 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.
>>>> 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")
>>>> 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.
>>>> 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.
>>>> 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.
>>>> _______________________________________________
>> cloud mailing list
>>cloud at pwg.org>>https://www.pwg.org/mailman/listinfo/cloud>>>>>>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>> _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Our website uses cookies on your device to give you the best user experience. By using our website, you agree to the placement of these cookies. To learn more, read our privacy policy. Read Privacy Policy