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

This is the way that I have implemented it in test apps.  It is the handler
app that will show the progress information.  I have not had a case yet
where the client app needs or is concerned about the progress of the action
that is being handled, other than on completion or on error.

I will launch a whole lot of new demo's soon so that we can all see them.

P

On Tue, Nov 15, 2011 at 9:37 PM, Charles Pritchard <chuck@jumis.com> wrote:

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


-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan