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

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 <chuck@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<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 20:37:23 UTC