On Mon, 12 Dec 2011 20:59:36 +0100, James Hawkins <jhawk...@google.com>
wrote:
On Thu, Dec 8, 2011 at 12:43 PM, Ian Hickson <i...@hixie.ch> wrote:
On Tue, 6 Dec 2011, James Hawkins wrote:
One of the critical pieces of the API is a declarative registration
which allows sites to declare which intents they may be registered for.
The current draft of the API calls for a new HTML tag, <intent>, the
attributes of which describe the service registration: [...]
Separate from the issue of what precisely the element should look like,
I
wonder if you could expand on the precise use case for the element. In
particular, I'm interested in whether this use case might also apply to
some of the register*Handler() methods we have now.
Ideally, it would be good to have the current protocol and content type
handlers and the Web Intent stuff all use a coherent and consistent API.
Absolutely, we're very keen on providing RPH/RCH functionality via Web
Intents. Let me start with the use case for the intent element, then
I'll get to R*H.
*** Use cases ***
The intent element serves as a declaration of functionality of a web
app. For example, Twitter exposes share functionality, Picnik exposes
editing functionality, Dropbox exposes pick/save functionality, etc.
Once the user accepts these registrations (gives permission), the UA
can connect a client requesting a given set of functionality to the
service that previously exposed that functionality.
The fact that the element is declarative is a win wrt sites that may
wish to crawl the web to index which web app handles which
functionality. See www.openintents.org/en/intentstable for an example
of this for Android Intents.
*** RPH/RCH ***
registerProtocolHandler gives services a way to imperatively expose
functionality that is to specific to protocols. Web Intents will
handle this use case by adding a scheme/URL pattern attribute to the
intent registration. Android Intents exposes scheme/URL pattern
filtering as well, so this addition moves Web Intents that much closer
to its model API.
navigator.registerProtocolHandler("mailto",
"https://www.example.com/?uri=%s";, "Mail Service");
becomes
<intent scheme="mailto" title="Mail Service">
Click here to install our Mail Service application!
</intent>
I'm not sure it's a good idea security-wise to have this feature as an
element. Many sites use black-list based HTML filtering of user input, to
filter out "bad" stuff like <script> elements. It's easy to argue that
they are already screwed, but we still have to think about it when adding
new features to the platform, because there are many such sites. It would
be easy to inject an <intent> tag to such sites, whereas it is harder to
call navigator.register*Handler.
Separately, I'm not so happy with having two APIs for the same thing. We
don't enable anything new, but we double the attack surface, the cost to
implement and test, authors need to not only learn both, but also need to
learn (and argue) about which to use, and so forth. register*Handler has
already been shipped in some browsers.
registerContentHandler allows services to imperatively expose
functionality that is specific to content types. Web Intents will
provide this use case by special-casing the intent element when no
action is provided for a particular MIME type.
navigator.registerContentHandler("image/png",
"http://www.example.com/?foo=%s";, "My Image Viewer");
becomes
<intent type="image/png" title="My Image Viewer">
Click here to install our Image Viewer application!
</intent>
Of course the fallback content is optional and determined by the
service, but we believe it's a great way to expose fallback
functionality via installable extensions/apps/whatnot.
The fallback would be more like "Your browser doesn't support the intent
tag", no?
*** Advantages ***
Client-side handling. For R*H, ?foo=%s normally requires server side
processing. With Web Intents, this data is passed completely
client-side on the intent object.
Wildcard matching. R*H does not allow wildcard matching, where as Web
Intents would allow a service to register for image/* in one succinct
registration.
I guess these features could be added to register*Handler without adding a
new element to register handlers.
Thanks,
James
--
Simon Pieters
Opera Software
