W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 14 Nov 2011 19:30:35 -0800
Message-ID: <4EC1DCDB.1080707@jumis.com>
To: Paul Kinlan <paulkinlan@google.com>
CC: Greg Billock <gbillock@google.com>, Rich Tibbett <richt@opera.com>, Dominique Hazael-Massieux <dom@w3.org>, Robin Berjon <robin@berjon.com>, public-webapps Group WG <public-webapps@w3.org>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
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
>     <chuck@jumis.com <mailto:chuck@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.
>
Received on Tuesday, 15 November 2011 03:31:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT