Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.comwrote: ** Does anybody use registerProtocolHandler in any real sense? Is registerContentHandler needed? It seems like Web Intents is an evolution on the concept. I don't think we're going to see convergence on those old methods. I'm ready to leave them both in favor of a yet-to-be announced candidate (web intents). URIs are better than protocols, and Intents are better than content handlers. In my opinion. RPH seems to be intended primarily for mailto: (I think that's where it is used.) I'm not sure what the RCH usage is like. It is definitely possible to imagine mapping UA handling of mailto: onto web intents. The way I think of it is like this: RPH is basically an action with a payload. RCH is essentially type info with the payload. Web Intents is kind of off-axis with both an action and a type as well as the payload. The idea (taking inspiration from the pluggable usage in the Android ecosystem) is that the action (analogous to the protocol) is a locus between the client and handling service which can be messaged to the user in a well-understood way. (i.e. instead of just saying here's some data, do whatever you want with it, which is a more content-type-driven As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent channel. It isn't clear to me as yet what to do about those. They definitely imply a more well-specified protocol to be pursued over that channel. Web Intents as an API doesn't really include or exclude that in the current form. On the other hand, it'd be a really nice application of the Web Intents permissions mechanism to be able to connect up, say, an SSH connection using Web Intents, so that I could write an in-browser terminal which could then be attached to a secure socket by the user. At this point, I'm not sure whether this kind of persistent connection use case is far enough from Web Intents to want to exclude it, or close enough to want to include it explicitly. Our early belief is that we aren't ruling it out with the proposed API, since MessageChannels could be provided or returned in the payload data. On the other hand, we haven't chosen to explicitly include such usage. But a lot of this stuff just comes with nice platform integration; I just tried passing Blob objects through intents in Chrome Tip-of-Tree with our prototype, and it Just Works, allowing a really appealing vision into what upload intents and file interactions could be like. Wins like that make me think that focusing on the sweet spot RPC interaction will not paint us into a corner. This is awesome, anything that is Serialzable is via the structured clone will work, so now we can pass File Objects between services, ImageData And MessageChannels. On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp On the earlier subject of demos, the current demos are at http://demos.webintents.org/ please note, twitpic does not work and I will be removing it from the list today until I have it working and I will be adding more over the coming days. re:Dave Ragget - the case is in one of the demos, save image, which hooks up with imgur API. There we pass the data from the client app (ImageStudio) to Imgur and the imgur service will handle the notifications to the user about the upload progress (via an XMLHttpRequest), at this point ImageStudio doesn't need to know or care about the progress of the upload, other than it completes or fails. P -Greg -- 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
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On 11/18/11 1:40 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com mailto:gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp My concern is the plumbing of Transferable. Sending Array Buffers across channels is great for short apps. Here's the webkit meta-bug as they work on postMessage semantics. https://bugs.webkit.org/show_bug.cgi?id=64629 It's a transfer intent. I'm transferring ownership of a buffer or a stream. It's still appropriate that mime types be specified. Many protocols have them. -Charles
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard ch...@jumis.com wrote: ** On 11/18/11 1:40 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.comwrote: As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp My concern is the plumbing of Transferable. Sending Array Buffers across channels is great for short apps. Here's the webkit meta-bug as they work on postMessage semantics. https://bugs.webkit.org/show_bug.cgi?id=64629 It's a transfer intent. I'm transferring ownership of a buffer or a stream. It's still appropriate that mime types be specified. Many protocols have them. -Charles Sure, you can defiantly pass data across them, what I was referring to (if I understand your point) is that the MessageChannel is used for protocols that are more complex that the request/response that webintents has now. And to ensure that both client and service are talking the same protocol then the mime type is for the protocol and not the data going across it. -- 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
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On 11/18/11 10:29 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/18/11 1:40 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com mailto:gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp My concern is the plumbing of Transferable. Sending Array Buffers across channels is great for short apps. Here's the webkit meta-bug as they work on postMessage semantics. https://bugs.webkit.org/show_bug.cgi?id=64629 It's a transfer intent. I'm transferring ownership of a buffer or a stream. It's still appropriate that mime types be specified. Many protocols have them. -Charles Sure, you can defiantly pass data across them, what I was referring to (if I understand your point) is that the MessageChannel is used for protocols that are more complex that the request/response that webintents has now. And to ensure that both client and service are talking the same protocol then the mime type is for the protocol and not the data going across it. Yes, I understand the reference. It's important that services are register themselves to appropriate mime types and intents. The intent field is a simple DOMString, and it's reasonably wide-open for use. Should we treat the mime type field in similar manner? Web messaging is so-easy to use, I'd expect a flood of micro-protocols. What's our plumbing to effectively work with the postMessage transfer semantic? It seems like transfer might be a special case intent. Everything else does a data copy. Transferring an array buffer means the current thread can no longer access that buffer. This is, approximately, what I'm thinking about: var intent = new Intent(http://webintents.org/transfer;, application/octet-stream+myprotocol, [messagePort, arrayBuffer]); The transfer intent signals that postMessage transfer semantics are going to be used. -Charles
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
I'd like to request that people stop sending posts about web intents to public-webapps@w3.org and public-device-a...@w3.org The new list exists and should be used: http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/ On 11/18/11, Charles Pritchard ch...@jumis.com wrote: On 11/18/11 10:29 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 7:23 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/18/11 1:40 AM, Paul Kinlan wrote: On Fri, Nov 18, 2011 at 2:15 AM, Greg Billock gbill...@google.com mailto:gbill...@google.com wrote: On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent On the subject of MessageChannels, my thoughts have been that you don't pass the data across it, as you would for say share image/*, but rather it is the initiation of a protocol - whose mime-type is yet to be determined; something like application/x-protocol-uucp My concern is the plumbing of Transferable. Sending Array Buffers across channels is great for short apps. Here's the webkit meta-bug as they work on postMessage semantics. https://bugs.webkit.org/show_bug.cgi?id=64629 It's a transfer intent. I'm transferring ownership of a buffer or a stream. It's still appropriate that mime types be specified. Many protocols have them. -Charles Sure, you can defiantly pass data across them, what I was referring to (if I understand your point) is that the MessageChannel is used for protocols that are more complex that the request/response that webintents has now. And to ensure that both client and service are talking the same protocol then the mime type is for the protocol and not the data going across it. Yes, I understand the reference. It's important that services are register themselves to appropriate mime types and intents. The intent field is a simple DOMString, and it's reasonably wide-open for use. Should we treat the mime type field in similar manner? Web messaging is so-easy to use, I'd expect a flood of micro-protocols. What's our plumbing to effectively work with the postMessage transfer semantic? It seems like transfer might be a special case intent. Everything else does a data copy. Transferring an array buffer means the current thread can no longer access that buffer. This is, approximately, what I'm thinking about: var intent = new Intent(http://webintents.org/transfer;, application/octet-stream+myprotocol, [messagePort, arrayBuffer]); The transfer intent signals that postMessage transfer semantics are going to be used. -Charles -- Sent from my mobile device
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On Mon, Nov 14, 2011 at 7:24 PM, Charles Pritchard ch...@jumis.com wrote: ** Does anybody use registerProtocolHandler in any real sense? Is registerContentHandler needed? It seems like Web Intents is an evolution on the concept. I don't think we're going to see convergence on those old methods. I'm ready to leave them both in favor of a yet-to-be announced candidate (web intents). URIs are better than protocols, and Intents are better than content handlers. In my opinion. RPH seems to be intended primarily for mailto: (I think that's where it is used.) I'm not sure what the RCH usage is like. It is definitely possible to imagine mapping UA handling of mailto: onto web intents. The way I think of it is like this: RPH is basically an action with a payload. RCH is essentially type info with the payload. Web Intents is kind of off-axis with both an action and a type as well as the payload. The idea (taking inspiration from the pluggable usage in the Android ecosystem) is that the action (analogous to the protocol) is a locus between the client and handling service which can be messaged to the user in a well-understood way. (i.e. instead of just saying here's some data, do whatever you want with it, which is a more content-type-driven As far as I can tell, the model doesn't prohibit, nor does it encourage, the passing of MessageChannel. It's very much made for an RPC style of communication, but if the message being passed back is a channel, well that's just fine. Am I mistaken? What I'm seeing is that we get MessageChannel for free, and there's no need to specify further. Individual Intent authors can do that themselves. Yes. We envision RPC-style request/response as the sweet spot for intents. We've definitely considered use cases which are better served by opening a persistent channel. It isn't clear to me as yet what to do about those. They definitely imply a more well-specified protocol to be pursued over that channel. Web Intents as an API doesn't really include or exclude that in the current form. On the other hand, it'd be a really nice application of the Web Intents permissions mechanism to be able to connect up, say, an SSH connection using Web Intents, so that I could write an in-browser terminal which could then be attached to a secure socket by the user. At this point, I'm not sure whether this kind of persistent connection use case is far enough from Web Intents to want to exclude it, or close enough to want to include it explicitly. Our early belief is that we aren't ruling it out with the proposed API, since MessageChannels could be provided or returned in the payload data. On the other hand, we haven't chosen to explicitly include such usage. But a lot of this stuff just comes with nice platform integration; I just tried passing Blob objects through intents in Chrome Tip-of-Tree with our prototype, and it Just Works, allowing a really appealing vision into what upload intents and file interactions could be like. Wins like that make me think that focusing on the sweet spot RPC interaction will not paint us into a corner. -Greg
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On 15/11/11 20:46, Paul Kinlan wrote: This is the way that I have implemented it in test apps. It is the handler app that will show the progress information. I have not had a case yet where the client app needs or is concerned about the progress of the action that is being handled, other than on completion or on error. So you are assuming the handler app always has a client-side API independent of the client app, even if the handler app is itself remote? I am looking forward to the seeing the use cases, as background for the assumptions. I will launch a whole lot of new demo's soon so that we can all see them. Looking forward to them. -- Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchard ch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard ch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
I may be misunderstanding things, but I was thinking that saving a file to the cloud. FileSaver and XHR have onprogress events so users don't wonder too-much about large file uploads. Those are the only cases I was thinking of. -Charles On 11/15/2011 10:31 AM, James Hawkins wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchardch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchardch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
RE: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
James wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). Is it possible to get your UCs published somewhere? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
http://usecases.webintents.org/ Though admittedly it's not complete, and we need to update the site with a list of use cases we've rejected. On Tue, Nov 15, 2011 at 11:30 AM, Josh Soref jso...@rim.com wrote: James wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). Is it possible to get your UCs published somewhere? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
Since we don't have background intents (many reasons why, though we looked into the idea), the service is responsible for displaying progress UI for this use case. For example imagine the service is Dropbox: the client initiates the upload action and Dropbox is selected as the service by the user. Likely Dropbox will use an inline disposition. The picker will be open showing the service until the operation is complete. Dropbox should show the upload progress UI in their UI in this case. Does that work in your mind? I'm not attempting to put the kibosh on this line of thought; I'm very open to any use cases where progression notifications to the client are necessary for a good UX. James On Tue, Nov 15, 2011 at 11:15 AM, Charles Pritchard ch...@jumis.com wrote: I may be misunderstanding things, but I was thinking that saving a file to the cloud. FileSaver and XHR have onprogress events so users don't wonder too-much about large file uploads. Those are the only cases I was thinking of. -Charles On 11/15/2011 10:31 AM, James Hawkins wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchardch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchardch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
This is the way that I have implemented it in test apps. It is the handler app that will show the progress information. I have not had a case yet where the client app needs or is concerned about the progress of the action that is being handled, other than on completion or on error. I will launch a whole lot of new demo's soon so that we can all see them. P On Tue, Nov 15, 2011 at 9:37 PM, Charles Pritchard ch...@jumis.com wrote: Yes, that works in my mind. -Charles On 11/15/11 12:36 PM, James Hawkins wrote: Since we don't have background intents (many reasons why, though we looked into the idea), the service is responsible for displaying progress UI for this use case. For example imagine the service is Dropbox: the client initiates the upload action and Dropbox is selected as the service by the user. Likely Dropbox will use an inline disposition. The picker will be open showing the service until the operation is complete. Dropbox should show the upload progress UI in their UI in this case. Does that work in your mind? I'm not attempting to put the kibosh on this line of thought; I'm very open to any use cases where progression notifications to the client are necessary for a good UX. James On Tue, Nov 15, 2011 at 11:15 AM, Charles Pritchardch...@jumis.com wrote: I may be misunderstanding things, but I was thinking that saving a file to the cloud. FileSaver and XHR have onprogress events so users don't wonder too-much about large file uploads. Those are the only cases I was thinking of. -Charles On 11/15/2011 10:31 AM, James Hawkins wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchardch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/**eventsource/http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchardch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox. -- 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
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On 11/13/11 3:18 PM, Paul Kinlan wrote: On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett ri...@opera.com mailto:ri...@opera.com wrote: Dominique Hazael-Massieux wrote: Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit : Hi a.) to register a URL endpoint as an intent provider the user must visit a web page (presumably hosted by the target device itself) and capture the intent registration from that page before that intent provider can be used within the UA. My understanding is that this is not a MUST at all, but the way Web-based services can be added by a user. Yes. The API as currently proposed has a way for web apps to register services, but it is not intended to limit the ability of the user agent to register services by other methods. If you look at our Chromium commits, we're experimenting with ways to register services through installation of web apps, for instance. Registering handlers through local network discovery or interaction with the host OS also seems like a promising direction. Has there been further movement toward the existing register*Handler APIs: http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers I've practiced with those methods and from a usability perspective, I'm starting to think those html5 methods are not going to be worth using. Whatever the end-case, Web Intents seems to be where the UI is going to evolve. I understand that from the Chromium-OS side, Web Intents is likely to take over the fileHandlers permission. That tells me that registerContentHandler is not going to happen. The intent model can support view with the associated MIME-type which is what regsiterContentHandler does. The point we need to discuss is registerContentHandler will implicitly start when a file is loaded with that mime-type, so should a UA initiate startActivity implicitly with a view, the detected mime type and the file data? Seems like the UA gets to make all of the decisions here. I think the disposition=inline vs. [a download] really sets up the intent well. If the anchor is marked for inline, it makes a lot of sense that the UA would check on its registered intents for handling it implicitly. There's no reason to push authors into triggering intents when the user can setup those preferences on their own. PDF is a good model for this one... it's a view situation and it's likely to have only one viewer, and it's also likely to be viewed inline. Mozilla's work on PDF.js is certainly showing the power of web app registration for this complex file format. I know if I register pdf.js as my PDF viewer, that's what I want to pop up. I also know that, if I'm running Chrome, I want, somewhere, the option of switching between the Foxit and Mozilla viewers. I'm not really happy with the Chrome interface for adding and removing registered protocol handlers. It's so buried, nobody is going to know about it. Web Intents really fills that gap of Open With... and context menus. I find the existing context-menu solution distasteful: a background page just so I can register a link? ugh!#$. Does anybody use registerProtocolHandler in any real sense? Is registerContentHandler needed? It seems like Web Intents is an evolution on the concept. I don't think we're going to see convergence on those old methods. I'm ready to leave them both in favor of a yet-to-be announced candidate (web intents). URIs are better than protocols, and Intents are better than content handlers. In my opinion. Thanks for the quick reply and good to ensure this stuff gets captured in the TF charter. As Chaals said, let's get going on this. The concept of Web Intents is great and we're not married to any particular proposal at this point. We can see if it works for our UCs when the task force kicks off. Clarke Stevens asked about a discovery mechanism whereby a client page discovers a set of local network devices which is then updated by an event driven mechanism. As currently sketched out, there's room in our web intents proposal for the return of a MessagePort for persistent communication. The proposal doesn't focus on that problem, though. It is aimed more at an RPC-style request/response interaction paradigm. Web Intents, the way we're currently thinking about it, has a lot to do with user consent to the connection between the applications. When there's a persistent connection, that consent model starts to break down. That
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On 11/10/11 3:10 PM, Greg Billock wrote: On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett ri...@opera.com mailto:ri...@opera.com wrote: Dominique Hazael-Massieux wrote: Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit : Hi a.) to register a URL endpoint as an intent provider the user must visit a web page (presumably hosted by the target device itself) and capture the intent registration from that page before that intent provider can be used within the UA. My understanding is that this is not a MUST at all, but the way Web-based services can be added by a user. Yes. The API as currently proposed has a way for web apps to register services, but it is not intended to limit the ability of the user agent to register services by other methods. If you look at our Chromium commits, we're experimenting with ways to register services through installation of web apps, for instance. Registering handlers through local network discovery or interaction with the host OS also seems like a promising direction. Has there been further movement toward the existing register*Handler APIs: http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers I've practiced with those methods and from a usability perspective, I'm starting to think those html5 methods are not going to be worth using. Whatever the end-case, Web Intents seems to be where the UI is going to evolve. I understand that from the Chromium-OS side, Web Intents is likely to take over the fileHandlers permission. That tells me that registerContentHandler is not going to happen. Chromium-OS is headed from a vendor-specific extension into web intents: http://code.google.com/chrome/extensions/fileBrowserHandler.html I'm OK with that. I want to make sure we're all aware of the divergence. I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox. Thanks for the quick reply and good to ensure this stuff gets captured in the TF charter. As Chaals said, let's get going on this. The concept of Web Intents is great and we're not married to any particular proposal at this point. We can see if it works for our UCs when the task force kicks off. Clarke Stevens asked about a discovery mechanism whereby a client page discovers a set of local network devices which is then updated by an event driven mechanism. As currently sketched out, there's room in our web intents proposal for the return of a MessagePort for persistent communication. The proposal doesn't focus on that problem, though. It is aimed more at an RPC-style request/response interaction paradigm. Web Intents, the way we're currently thinking about it, has a lot to do with user consent to the connection between the applications. When there's a persistent connection, that consent model starts to break down. That said, there are definitely use cases for which establishing a persistent connection is appropriate. I'm eager to discuss how to best handle those cases as the TF starts up. I think that'll be a key focus of refinement. Hixie made a good point when he asked us to review Web Messaging. Intents as it's implemented by Google -- and it's already happening -- Google started this push awhile ago and I get the impression that Paul Kinlan has high level support -- intents as it's implemented is built upon Web Messaging and postMessage dynamics. postMessage has MessagePort and Transferable arrays (thank goodness). I believe those semantics already solve issues of RPC, bi-di and zero-copy. They've had years of work put into them to get to this place of consensus. timeless brought up some excellent corner cases that I hope are discussed soon in the upcoming TF mailing list. That stated, I think building Intents atop postMessage is the right move. Web Messaging has already solved many of the difficult problems. As far as I can tell, Web Intents adds another high level semantic: the Intent
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
Hi, CIL On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard ch...@jumis.com wrote: ** On 11/10/11 3:10 PM, Greg Billock wrote: On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett ri...@opera.com wrote: Dominique Hazael-Massieux wrote: Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit : Hi a.) to register a URL endpoint as an intent provider the user must visit a web page (presumably hosted by the target device itself) and capture the intent registration from that page before that intent provider can be used within the UA. My understanding is that this is not a MUST at all, but the way Web-based services can be added by a user. Yes. The API as currently proposed has a way for web apps to register services, but it is not intended to limit the ability of the user agent to register services by other methods. If you look at our Chromium commits, we're experimenting with ways to register services through installation of web apps, for instance. Registering handlers through local network discovery or interaction with the host OS also seems like a promising direction. Has there been further movement toward the existing register*Handler APIs: http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers I've practiced with those methods and from a usability perspective, I'm starting to think those html5 methods are not going to be worth using. Whatever the end-case, Web Intents seems to be where the UI is going to evolve. I understand that from the Chromium-OS side, Web Intents is likely to take over the fileHandlers permission. That tells me that registerContentHandler is not going to happen. The intent model can support view with the associated MIME-type which is what regsiterContentHandler does. The point we need to discuss is registerContentHandler will implicitly start when a file is loaded with that mime-type, so should a UA initiate startActivity implicitly with a view, the detected mime type and the file data? Chromium-OS is headed from a vendor-specific extension into web intents: http://code.google.com/chrome/extensions/fileBrowserHandler.html I'm OK with that. I want to make sure we're all aware of the divergence. I am currently tracking this. I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox. Thanks for the quick reply and good to ensure this stuff gets captured in the TF charter. As Chaals said, let's get going on this. The concept of Web Intents is great and we're not married to any particular proposal at this point. We can see if it works for our UCs when the task force kicks off. Clarke Stevens asked about a discovery mechanism whereby a client page discovers a set of local network devices which is then updated by an event driven mechanism. As currently sketched out, there's room in our web intents proposal for the return of a MessagePort for persistent communication. The proposal doesn't focus on that problem, though. It is aimed more at an RPC-style request/response interaction paradigm. Web Intents, the way we're currently thinking about it, has a lot to do with user consent to the connection between the applications. When there's a persistent connection, that consent model starts to break down. That said, there are definitely use cases for which establishing a persistent connection is appropriate. I'm eager to discuss how to best handle those cases as the TF starts up. I think that'll be a key focus of refinement. Hixie made a good point when he asked us to review Web Messaging. Intents as it's implemented by Google -- and it's already happening -- Google started this push awhile ago and I get the impression that Paul Kinlan has high level support -- intents as it's implemented is built upon Web Messaging and postMessage dynamics. postMessage has MessagePort and Transferable arrays (thank goodness). I believe those semantics already solve issues of RPC, bi-di and zero-copy. They've had years of work put into them to get to this place of consensus. timeless brought up some excellent corner cases that I hope are discussed
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 11:18 PM, Paul Kinlan paulkin...@google.com wrote: Hi, CIL On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard ch...@jumis.comwrote: ** On 11/10/11 3:10 PM, Greg Billock wrote: On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett ri...@opera.com wrote: Dominique Hazael-Massieux wrote: Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit : Hi a.) to register a URL endpoint as an intent provider the user must visit a web page (presumably hosted by the target device itself) and capture the intent registration from that page before that intent provider can be used within the UA. My understanding is that this is not a MUST at all, but the way Web-based services can be added by a user. Yes. The API as currently proposed has a way for web apps to register services, but it is not intended to limit the ability of the user agent to register services by other methods. If you look at our Chromium commits, we're experimenting with ways to register services through installation of web apps, for instance. Registering handlers through local network discovery or interaction with the host OS also seems like a promising direction. Has there been further movement toward the existing register*Handler APIs: http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers I've practiced with those methods and from a usability perspective, I'm starting to think those html5 methods are not going to be worth using. Whatever the end-case, Web Intents seems to be where the UI is going to evolve. I understand that from the Chromium-OS side, Web Intents is likely to take over the fileHandlers permission. That tells me that registerContentHandler is not going to happen. The intent model can support view with the associated MIME-type which is what regsiterContentHandler does. The point we need to discuss is registerContentHandler will implicitly start when a file is loaded with that mime-type, so should a UA initiate startActivity implicitly with a view, the detected mime type and the file data? Chromium-OS is headed from a vendor-specific extension into web intents: http://code.google.com/chrome/extensions/fileBrowserHandler.html I'm OK with that. I want to make sure we're all aware of the divergence. I am currently tracking this. I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox. Thanks for the quick reply and good to ensure this stuff gets captured in the TF charter. As Chaals said, let's get going on this. The concept of Web Intents is great and we're not married to any particular proposal at this point. We can see if it works for our UCs when the task force kicks off. Clarke Stevens asked about a discovery mechanism whereby a client page discovers a set of local network devices which is then updated by an event driven mechanism. As currently sketched out, there's room in our web intents proposal for the return of a MessagePort for persistent communication. The proposal doesn't focus on that problem, though. It is aimed more at an RPC-style request/response interaction paradigm. Web Intents, the way we're currently thinking about it, has a lot to do with user consent to the connection between the applications. When there's a persistent connection, that consent model starts to break down. That said, there are definitely use cases for which establishing a persistent connection is appropriate. I'm eager to discuss how to best handle those cases as the TF starts up. I think that'll be a key focus of refinement. Hixie made a good point when he asked us to review Web Messaging. Intents as it's implemented by Google -- and it's already happening -- Google started this push awhile ago and I get the impression that Paul
