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

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 18:32:27 UTC