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