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