Re: [DRAFT] Web Intents Task Force Charter

-------------------------------------------------
From: "timeless" <timeless@gmail.com>
Sent: Friday, November 11, 2011 3:23 AM
To: "Marcos Caceres" <w3c@marcosc.com>; <public-webapps@w3.org>; 
<public-device-apis@w3.org>
Subject: Re: [DRAFT] Web Intents Task Force Charter

> Some of this really should wait until there's a list.
>
> I believe that generally one wants to adjust audio as close to the
> source as possible, in which case the TV doesn't know anything.
>
> Some parallels:
> A. If you have a cable box => vcr => tv in old serial fashion and use
> old fashion remotes, changing the audio w/ the cable box remote
> adjusts the audio sent by that box to the vcr, the tv's audio level
> isn't affected (but the cable box can insert an overlay indicating
> level and hide it after some interval).
> B. If you use digital audio out on your Mac to an external device,
> volume controls disappear from the mac (it expects you to use your
> stereo's mixer instead).
> - here if an intent user decides you're using a tv, it could choose to
> hide audio controls (deferring to the tv). Note that I consider this
> more of a bug than a feature, but...
>
> Anyway, to your underlying question:
> Android Intents and I believe some of the web Intents proposals have two 
> forms:
> 1. Fire and forget (mailto:, outbound video/audio/document)
> 2. Establish bidirectional communications link



I see two variants here. Simple request-response case (contact picker) and a 
continuous dialog case. I am wondering should all intents expose some UI. 
Can they just expose a URL and allow the caller to use those URLs with XHR 
or EventSource.




>
> Defining how to make #2 work should be in scope for the TF and Out Of
> Scope while defining its Charter.
>
> #2 is obviously more exciting for vendors trying to proxy to non web
> things, but IMO that's an implementation detail or potentially a
> supplemental Note/Specification.
>
> On 11/10/11, Marcos Caceres <w3c@marcosc.com> wrote:
>>
>>
>> --
>> Marcos Caceres
>>
>>
>> On Thursday, November 10, 2011 at 7:56 PM, Rich Tibbett wrote:
>>
>>> Marcos Caceres wrote:
>>> >
>>> > On Thursday, November 10, 2011 at 5:01 PM, Robin Berjon wrote:
>>> >
>>> > > It's important to separate Intents as currently proposed and what we
>>> > > collectively want out of them. In order to move fast we probably 
>>> > > don't
>>> > > want to pile up a zillion features there, but we equally certainly
>>> > > don't want this to turn into a rubber-stamping exercise. So bring 
>>> > > the
>>> > > UCs on!
>>> > >
>>> > > - Hide quoted message -
>>> > > > Perhaps someone could take the time to describe exactly how a user
>>> > > > could communicate with an existing TV device in their home from a
>>> > > > web browser supporting web intents based on the above 
>>> > > > requirements?
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > We actually agreed that folks in the Discovery/Home Networking gang
>>> > > would do just that, to see if it flies.
>>> > Also, a prototype might help here …. i.e., it's not up to the WG to
>>> > explain how it does what you want, but up to you to show that it 
>>> > doesn't
>>> > do something you want through a prototype (or similar) to do. If your
>>> > prototype breaks down because the intents system doesn't work without
>>> > extensions, then we have something to work from.
>>> >
>>> > Agree?
>>>
>>> Yes. I don't doubt this logic :)
>> A use case I keep thinking about is:
>>
>>  1. I'm at Youtube.com, and I want to watch a video on my tv.
>>  2. I tell youtube, "hey, sent this to my TV".
>>  3. Video starts playing on my TV.
>>  4. I turn the audio up/down on the youtube video (or I scrub the 
>> timeline).
>> How does that work? Is that all still done over HTTP and the intent 
>> (i.e.,
>> the audio control)?
>>
>> I guess it's like the "intent" is ongoing while some activity is 
>> happening
>> (watching the video on my tv). I don't know if the current proposal 
>> supports
>> such a thing or if it's more "fire and forget".
>>
>> Anyway, just thinking out loud… guess we can pick this up in the new 
>> list.
>>
>>
>
> -- 
> Sent from my mobile device
>

Received on Friday, 11 November 2011 10:09:54 UTC