Re: Web Intents and Home Networking Scenarios

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.

-- 
-,Bjartur

Received on Wednesday, 18 January 2012 22:25:50 UTC