Re: Adding Web Intents to the Webapps WG deliverables

On Thu, 22 Sep 2011, James Hawkins wrote:
> >
> > But this is a non-problem. In practice, we have plenty of examples of 
> > spaces where conflicts don't happen despite not having used long names 
> > such as URLs. For example:
> >
> >  - rel="" values in HTML
> >  - element names in HTML
> >  - MIME type names
> >  - scheme names
>
> We are following the model set by Android Intents by bootstrapping the 
> feature with a list of actions that we agree will be far-reaching and 
> useful, e.g., share, pick, edit, save.
> 
> The Android Intents system employs java-style namespacing, e.g., 
> android.intent.action.EDIT is the string value of the ACTION_EDIT 
> constant.  The idea is that vendors can add to the intent ecosystem by 
> creating new actions, usually by setting the namespace appropriately, 
> e.g., org.openintents.action.CALCULATOR.
> 
> When designing the format of the Web Intents action string, we got a lot 
> of feedback that the java namespacing is not native to the web and that 
> URLS would be a better namespacing scheme.  This gave us the added 
> benefit that, by setting precedence with the default list actions, 
> action URLs serve both as a namespace mechanism and the page at the URL 
> contains documentation for the particular action.  If a developer wants 
> to find out more about http://webintents.org/share, all she has to do is 
> visit that URL (try it!).
> 
> If, for example, Twitter decided to add a new action, say 'tweet', they 
> could set the action string to http://dev.twitter.com/tweet which would 
> contain the input/output specification for this action.

Using URLs is ugly and unnecessary and makes the API look far more 
complicated than necessary. I understand that Web "experts" are always 
telling everyone to use URLs, but IMHO they are strongly misguided in 
this. I recommend following the pattern actually used on the Web for every 
verb and noun other than those identify Web pages, and using simple 
identifiers. As I mentioned above, it's what we use on the Web for pretty 
much everything -- rel="", element names, MIME types, schemes, HTTP verbs, 
<meta> names, HTTP headers, pretty much everything.


> > > We need to update the spec.  The UA should track the pages that 
> > > declare intent registration and if the user has the intent installed 
> > > and the tag is no longer on the tracked page(s) the UA should remove 
> > > the registration.
> >
> > This would not work well with sites that only show the intent element 
> > to users who are logged in with an account that is fully paid up...
>
> Can you expand on this?  I don't see the problem.  The intent element 
> can be dynamically removed, if needed, and the intent will be 
> unregistered in the UA.  If it happens at invocation point (likely), the 
> service has a chance to ask the user to pay up (?)

If the registration is only removed when you explicitly visit the page, 
then it doesn't work because you're not going to be visiting the page very 
often, especially if the handler is no longer in existence.

If the registration is removed automatically in the background when the 
page no longer has the declaration, then as soon as I log out of Google, 
all my Google handlers will go away, rather than continuing to work but 
asking me to log in when I use them.


> > > > Here's a possibly simpler proposal:
> > > >
> > > >  - to register:
> > > >
> > > >   navigator.registerIntentHandler(intent, filter, url, kind);
> > > >     intent = string like "share", "play"
> > > >     filter = MIME type (foo/bar) or MIME wildcard (foo/* or */*)
> > > >     url = page to load to handle intent
> > > >     kind = a flag indicating if the page should be:
> > > >       - always opened in a new tab
> > > >       - opened in the intent handler dialog (inline/pop-up)
> > > >       - opened in an existing tab if possible, else a new tab
> > > >
> > > >  - to check if registered, to unregister:
> > > >
> > > >   navigator.isIntentHandlerRegistered(intent, filter, url);
> > > >   navigator.unregisterIntentandler(intent, filter, url);
> > > >
> > > >  - to invoke intent:
> > > >
> > > >   var port = navigator.handleIntent(intent, filter);
> > > >   port.postMessage(data);
> > > >   port.onmessage = function (event) { handle(event.data) };
> > >
> > > We thought about this, we didn't want developers to have to worry 
> > > about when they think they should start to postMessage, or finish 
> > > listening to the onmessage event.
> >
> > What is there to think about? They send one message, they receive one 
> > back. I don't understand why this would be complicated.
>
> When does the port close?

When the window closes. The same problem exists in the model described in 
the spec today, as far as I can tell.


> What happens if I call postMessage() again, after receiving the response 
> from the service?

It posts the message. Why is this a problem?


> We designed the API to be as simple as possible, in this case by being 
> explicit.  Less questions need to be asked, less chances to shoot 
> oneself in the foot.

I think your proposal is more complicated than what I have above, and 
doesn't have any fewer opportunities to shoot oneself in the foot.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 2 April 2012 23:31:39 UTC