- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 15 Nov 2011 11:15:42 -0800
- To: James Hawkins <jhawkins@google.com>
- CC: Paul Kinlan <paulkinlan@google.com>, 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>
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 Pritchard<chuck@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<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 19:16:17 UTC