Re: Adding Web Intents to the Webapps WG deliverables

Hi Ian,

Here are some answers, I have worked closely with the team on getting this
ready so if I miss anything out they will be able to fill in the blanks.

Q: Why are the verbs URLs?

Verbs don't have to be URL's but a URL will allow us a point of reference to
documentation, versioning and namespacing allowing verbs with similar names
but by a different provider to not conflict with each other (thus allowing
developers to come up with their own schemes and APIs outside of
standardisation).

Q: Why are some verbs hard-coded into the API?

Convenience and ensuring there is a consistent use of the first set of
intents that cover the most common initial use cases.

Q: How are types matched?

I don't know the best phrase, mime-typedness.  A direct
string comparison unless there is a * after the / (image/*) which then means
every image.

Q: Why not just improve both navigator.registerContentHandler and
navigator.registerProtocolHandler?

WI encompasses aspects of both of these API's - but more importantly there
are some paradigms we wish to bring that will not fit in to either directly.
 We want one consistent way of delivering data to applications, we want it
to be a client-side delivery mechanism, and we want applications to be able
to tell the action it supports and the data types it can handle.

For instance WI can have application success and failure semantics that are
proxied via the UA so it can respond.  It has a much more succinct syntax
for processing data and establishing channels of communication.  Launching
an app via RPH whilst in its simplest form can be embedded in an anchor has
many complexities for setting up and managing communication across windows.

WI's data delivery is entirely driven on the client, registering a protocol
handler requires a URL substitution which forces the developer to either
require a server to process the response (via querystring) or to have a
complex postMessage dance to deliver data, or to manage data with the hash
parameter; the latter is troublesome because of limits in URL sizes as well
as the extra burden to the developer if they are already extensively using
hash and onhashchange; the former is troublesome because it will not work
offline; and the 2nd point, we strongly believe that client and service in
all but the simplest scenarios should not have to tell each other they are
ready before they deliver each other the data - the current situation for
web developers is that the receiving app needs to tell the calling app that
it is ready for data which leads to trying to come up with a standard
message processing code that all apps agree on.  We want to get to a
scenario that allows developers not to have to think of the three different
ways they may need send data to any one particular app.

Q: How does an already-open page get to handle an action? e.g. say GMail
wants to handle the "share" intent, and the user already has GMail open,
and the user clicks a "share" button on Flickr. How does the existing
GMail instance get the notification?

If it was a share, we would envisage the UI to open the "compose" email
function rather than the full interface.  The context in this case wouldn't
make sense to open the full app up.  However it is entirely up to the app
what it does and in the case of it opening the full UI, it would open a new
instance because we only deliver the data once and it is placed on the
intent object.

Q: In particular, why are intents registered via a new HTML element rather
than an API? How do you unregister? How do you determine if the intent was
registered or not? How do you conditionally register (e.g. once the user
has paid for the service)?

External discoverability, indexing and scraping is a very important part of
the intent tag, understanding the API points of an application is very
powerful to external systems - via an API we lose this ability, or at least
make it fiendishly hard to discover. Flexibility for the UA; the UA gets a
much richer understanding of the capabilities of an application, allowing it
to have more control of how it presents and manages the intents and
registration to the user.  If it is available as a tag it
allows screen-readers or other accessibility tools to be able to indicate
that A) and intent might need to be installed, or that B) the application is
a handler for something at load time rather than at some point in the
applications lifecycle.

Developer experience is another important reason for the tag: We didn't want
the developers to have to think too hard about enabling their apps
to receive data; questions developers ask often of an API is "when should I
call the code", should it be in onload, before, after?  Given our experience
working with developers, the more steps or potential questions that are
raised in a developers head about implementing functionality, the more
likely they are to de-prioritise the work in favor of other work.  We
considered the cases of the Notifications API, where there is a semi-complex
dance of checking for permissions, requesting for permission and
then executing the notification - the burden falls on the developer to keep
track of whether they think the user has notifications enabled in their app
as well as by the UA and the developer just doesn't bother to implement it.
 A declarative registration removes a lot of these issues and moves the
management more in to the UA and away from the developer.  Registration
doesn't seem in the majority of cases that it should need to be actively
invoked via an API, we have seen many services offer support for
registerProtocolHandler and they are tending to do it onload rather than as
the result of a click on an install button.

Unregistering would be handled by the UA's management interface directly by
the user. Following from the previous point of registration, we are yet to
see many services offer to uninstall a protocolHandler from their app.  The
business part of my mind also says "why would I offer user's the ability to
remove my app as a handler and risk losing the integration points". Once
developers integrate they are very unlikely to un-integrate, and to us it
makes more sense generally to have one central place in the UA to manage the
options for the user.

Conditional registration can be handled on the client or server, it is about
the presence of the intent tag - when the tag is in the DOM the UA will pick
this up and offer the install prompt (when it determines that it should).
This allows you to manage it in a paywall (maybe you have a template that
will render the tag in the paywall), or as the result of some client-side
action (the developer will add <intent> dynamically to the DOM).

Determining if the intent was registered - is that in the context of the app
knowing the user clicked "install" to a prompt or for external apps to know
that there is a handler? In the case of the former, we haven't got that
speced - it could be an event on the elements however my question is: why do
you need to know? in the case of the latter we didn't want to offer it as
part of the API for the same concerns that vendors have expressed for
registerProtocolHandler.

Thanks,
P

On Tue, Sep 20, 2011 at 4:53 AM, Ian Hickson <ian@hixie.ch> wrote:

>
> Why not just improve both navigator.registerContentHandler and
> navigator.registerProtocolHandler?
>
> In particular, why are intents registered via a new HTML element rather
> than an API? How do you unregister? How do you determine if the intent was
> registered or not? How do you conditionally register (e.g. once the user
> has paid for the service)?
>
> How does an already-open page get to handle an action? e.g. say GMail
> wants to handle the "share" intent, and the user already has GMail open,
> and the user clicks a "share" button on Flickr. How does the existing
> GMail instance get the notification?
>
> Why are the verbs URLs?
>
> Why are some verbs hard-coded into the API?
>
> How are types matched?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>


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