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

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<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:38:03 UTC