- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Thu, 02 Feb 2012 13:42:15 -0000
- To: "public-web-intents@w3.org" <public-web-intents@w3.org>
On Thu, 26 Jan 2012 17:02:30 -0000, Clarke Stevens <C.Stevens@cablelabs.com> wrote: > Claes, > > This is a nice summary and is consistent with the requirements I want to > support. > +1 /g > -Clarke > > On 1/26/12 8:53 AM, "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com> > wrote: > >> Hi Paul and others, >> >> This comes back to the issue on "what is a Service in the context of Web >> Intents?" that I highlighted in [1]. >> >> Furthermore, printing was an example and we should probably more have >> the >> use cases in [2] in focus. >> >> I see that we have two issues to discuss: >> >> 1. Broadening/extending the concept of Web Intents Service to allowing >> Services to be not only represented as web pages but also as >> services/devices dynamically discovered through some underlying low >> level >> discovery/communication mechanism such as UPnP or Bluetooth. These >> dynamic Services may or may not have a UI. >> 2. How to achieve a persistent communication/control relation between >> the >> Client web application and the Service. >> >> So 1 means that the Web Intents framework implementation in the UA >> (optionally) should support: >> - Access to common low level discovery/communication mechanisms such as >> UPnP and Bluetooth. >> - Dynamic creation and registration of Web Intents Services. >> Correct? >> >> For 2 Dave proposes a "handler object" as payload, but Greg states this >> will not work based on the current definition on Intents payload. Paul >> suggests using HTML5 message channels and Service specific JSON >> protocols >> on this channel. As HTML5 Web Messaging is designed to support >> communication between two browsing contexts I wonder if this mechanisms >> can be used to communicate between the Client web application and a >> Service that is dynamically created by the Web Intents framework in the >> UA? Or should the UA dynamically create a browsing context representing >> the discovered Service in this case? >> >> My view on the strength of Web Intents is that a Service could reside >> anywhere. The Client web application should not have to know anything >> about where the Service resides. So, if we look at the use case "Push >> Play" in [2] the TV could be found in the local network and discovered >> through UPnP but it could also be found through the global cloud. I >> assume that the TV Service (in Web Intents context) is dynamically >> created by the Web Intents implementation for the local case but how is >> it for a TV discovered through the cloud? Under all circumstances we >> want >> the Client application to be able to use the same commands/protocol >> irrespective of where the TV resides. >> >> Best regards >> Claes >> >> >> >> [1] >> http://lists.w3.org/Archives/Public/public-web-intents/2012Jan/0035.html >> [2] http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents >> >> >> >>> -----Original Message----- >>> From: Paul Kinlan [mailto:paulkinlan@google.com] >>> Sent: den 26 januari 2012 03:46 >>> To: James Hawkins >>> Cc: Dave Raggett; public-web-intents@w3.org >>> Subject: Re: Proposal for using web intents for a print intent >>> >>> My use case is for www.imagemator.com to have a print button where I >>> can go and send the photo directly to Costco's web print service. >>> >>> Not wanting to speak (but I will take a leap of judgement) for Claes >>> and Dave, they want to be able to interact with the Device (I have a >>> couple of partners that I work with that would like the same thing) >>> directly and be able to manage the printer status, so that they can >>> interact with the printer to recieve higher level notifications and >>> also manage the print queue (perhaps to cancel a job) via the app and >>> not an external manager app. >>> >>> To this effect I think this can be done with the methods that we have >>> been discussing in the past. >>> >>> var channel = new MessageChannel(); >>> var port2 = channel.port2(); >>> var port1 = channel.port1(); >>> port2.onmessage = function(e) { >>> if(e.data.message == "notify") { .. } >>> if(e.data.message == "ready") { port1.postMessage({ "message" : >>> "start_job", data: data, options: { media_size: "A4", "color" : true} >>> }); >>> >>> }; >>> var intent = new Intent("http://webintents.org/print", >>> "appiliation/x-printer-controler", channel.port1()); >>> window.navigator.startActivity(intent, function() { /* yay */ }); >>> >>> It has some message protocol nitty gritty, but you can abstract that >>> in a higher level API. >>> >>> I imagine I would use the Intent system to print as follows: >>> >>> var urls = ["url1", "url2", "url3"] >>> var intent = new Intent("http://webintents.org/print", >>> "appiliation/pdf", urls]); >>> window.navigator.startActivity(intent, function() { /* yay */ }); >>> >>> With costco being a handler, and just accepting the images I passed in. >>> >>> >>> >>> On Wed, Jan 25, 2012 at 6:30 PM, James Hawkins <jhawkins@chromium.org> >>> wrote: >>> > OK I think we're getting closer. Can you explain this in terms of >>> example >>> > client(s) and respective service(s)? >>> > >>> > >>> > On Wed, Jan 25, 2012 at 6:28 PM, Paul Kinlan <paulkinlan@google.com> >>> wrote: >>> >> >>> >> I know this email was a little more complex way of interacting with >>> >> printing devices, but the simpler case is much like "share" intent >>> >> where there a cloud based printing solutions that accept just a PDF >>> or >>> >> document, the theory being that you "print" a document and via >>> >> webintents it sends it to an API or service that will render it to >>> >> paper or something else that can than be mailed to someone. >>> >> >>> >> I always imagined it to be something like: >>> >> + >>> >> >>> https://printonline.fedex.com/v2.3.0/?s_kwcid=TC|16501|print%20companie >>> s||S|b|9706081275&&cmp=KNC-1000441-003-002-0950-0010000-US-US-EN- >>> GPOL00000000000&x=1&s_kwcid=TC|16501|print%20companies||S|b|9706081275 >>> >> Or >>> >> Costco's send to print images online and then collect them in the >>> >> store >>> >> >>> (http://www.costcophotocenter.com/account/login.aspx?ReturnUrl=%2falbum >>> %2f) >>> >> >>> >> The verb "save" and "share" doesn't quite fit the intention of the >>> user. >>> >> >>> >> On Wed, Jan 25, 2012 at 6:07 PM, James Hawkins >>> <jhawkins@chromium.org> >>> >> wrote: >>> >> > What is the use case for this? What I'm really asking is what do >>> you >>> >> > need >>> >> > that is not handled by existing browser printing, e.g., >>> window.print? >>> >> > >>> >> > Thanks, >>> >> > James >>> >> > >>> >> > On Wed, Jan 25, 2012 at 3:51 AM, Dave Raggett <dsr@w3.org> wrote: >>> >> >> >>> >> >> I spotted an error in my example: >>> >> >> >>> >> >> On 25/01/12 11:40, Dave Raggett wrote: >>> >> >> >>> >> >> > // now start the activity and redirect >>> >> >> > // the onSuccess, and onFail functions >>> >> >> > // to methods on the intent data object >>> >> >> > >>> >> >> > window.navigator.startActivity(intent, >>> >> >> > function (data) { intent.success(data); }, >>> >> >> > function (data) { intent.fail(data); } >>> >> >> > ); >>> >> >> >>> >> >> Should have been: >>> >> >> >>> >> >> window.navigator.startActivity(intent, >>> >> >> function (data) { intent.data.success(data); }, >>> >> >> function (data) { intent.data.fail(data); } >>> >> >> ); >>> >> >> >>> >> >> sorry about that. >>> >> >> -- >>> >> >> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett >>> >> >> >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Paul Kinlan >>> >> Developer Advocate @ Google for Chrome and HTML5 >>> >> G+: http://plus.ly/paul.kinlan >>> >> t: +447730517944 >>> >> tw: @Paul_Kinlan >>> >> LinkedIn: http://uk.linkedin.com/in/paulkinlan >>> >> Blog: http://paul.kinlan.me >>> >> Skype: paul.kinlan >>> > >>> > >>> >>> >>> >>> -- >>> Paul Kinlan >>> Developer Advocate @ Google for Chrome and HTML5 >>> G+: http://plus.ly/paul.kinlan >>> t: +447730517944 >>> tw: @Paul_Kinlan >>> LinkedIn: http://uk.linkedin.com/in/paulkinlan >>> Blog: http://paul.kinlan.me >>> Skype: paul.kinlan >> >> > -- Giuseppe Pascale TV & Connected Devices Opera Software
Received on Thursday, 2 February 2012 12:42:46 UTC