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<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.
