RE: Web Intents and Home Networking Scenarios

Makes sense.

Is there another mechanism that you know of to accomplish sync across devices and/or apps?

Thanks!
-Paul



-----Original Message-----
From: Greg Billock [mailto:gbillock@google.com] 
Sent: Tuesday, January 24, 2012 5:45 PM
To: WebIntents
Subject: Re: Web Intents and Home Networking Scenarios

I'd tend to see that case more as a single application running across
multiple screens. Web Intents is more about passing information
between applications.

Now if the applications can use that passed data to facilitate a tight
synchronization, that's fine, but I don't think we should envision Web
Intents as fulfilling that directly. The user-in-the-loop semantics of
web intents mean they are async from the point of view of the client
and service apps, so the feature is ill suited for n-screen kinds of
time coordination.

On Tue, Jan 24, 2012 at 11:24 AM, GAUSMAN, PAUL <pg2483@att.com> wrote:
> In an n-screen scenario, the user experience offered by a web page using video with embedded cues or synced to a clock (e.g. the video itself or an external reference) could find that the pieces required to perform the experience are running on separate devices. Is there a DLNA supported mechanism for transferring cueing events to cooperating screens and/or bridging temporal reference across multiple devices?
>
> Thanks!
> -Paul
>
>
> -----Original Message-----
> From: Paul Kinlan [mailto:paulkinlan@google.com]
> Sent: Wednesday, January 18, 2012 11:04 PM
> To: Bjartur Thorlacius
> Cc: Giuseppe Pascale; WebIntents
> Subject: Re: Web Intents and Home Networking Scenarios
>
> On Wed, Jan 18, 2012 at 2:25 PM, Bjartur Thorlacius
> <svartman95@gmail.com> wrote:
>>
>> On Mon, 16 Jan 2012 12:06:06 -0000, Giuseppe Pascale <giuseppep@opera.com> wrote:
>>>
>>> On Fri, 13 Jan 2012 23:32:23 +0100, Bjartur Thorlacius <svartman95@gmail.com> wrote:
>>>>
>>>> What is the use case for not allowing the user to show a video somewhere else? Whether to show videos on a secondary screen or what video decoder to use depends more on the circumstances of the viewer(s) than the video server.
>>>
>>> indeed, but the functionality could be handled/mediated by the application
>>>
>> It is handled by an application of my choice.
>>
>>
>>> Here what we want to achieve is a 2 (or n) screens experience, where maybe I have a tablet, find a video, push it to the main TV screen but keep using the application to see additional content and maybe control the video being showed on the TV screen. Since this involve communication between 2 devices, I'm not sure this can be achieved only with a link (unless this is a browser feature of course, but we are arguing for a solution that can be handled by apps rather than browsers/extensions).
>>
>> You are assuming that the content browser and the media player must be the same application. On the Windows box I am typing this message on I discover music using Windows Explorer and feed it to VLC. I might just as well have navigated to music files in a web browser. The web page would not and need not know whether I used speakers or headphones. It would not and need not know whether I played it at all. Most importantly _it would not need to consider the possibility of users wishing to do something with content_. A page using <a href type> will not be able to forget to script a button for those poor souls who want to process and/or view their content in an unusual manner. It will never find it in the situation where a common use case works, but a separate Intent button is subtly broken due to code rot. Hidden content has shown that the Web is most certainly not immune to rot.
>>
>> When a user right-clicks or long-taps on a link, presses Shift+Enter after activating a link, or hovers over a link, the browser has an opportunity to suggest actions on the linked resource. Populating the context menu with actions a la IE accelerators would be a great thing. The Web Intents client API, on the other hand, only makes sense when a website links to content that it knows the user wants to modify externally and feed back to the linking website. All other use cases I can think of (e.g. view, phone, search, store verbatim, modify and store, modify and distribute elsewhere, and forward, share or verbatim redistribution) are or will be better served by forms, in the case of discover and pick, nothing, in the case of search for URIs with a given authority part, or hyperlinks.
>>
>> Scripts must be able to suggest users view files and ask users for modified versions of provided files. Scripts are able to do the former, if not using an elegant API.
>
> I am sorry but I am having a really hard time understanding what you
> are stating in the last two paragraphs
>
> Are you saying that invocation of an intent should not have to be
> scripted?  For example in the case of <input type="file"
> accepts="image/*" /> should delegate to the intent system allowing the
> user to choose a file from the file system or their preferred service?
> And the browser should be able to "insert" actions in to a context
> menu?
>
> The former, I wish to see, the later in Chrome's case in the short
> term can be handled by extensions, and in fact I have the extensions
> ready in the github repository.
>
> P
>>
>> --
>> -,Bjartur
>>
>
>
>
> --
> 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
>
>

Received on Tuesday, 24 January 2012 23:28:30 UTC