Re: [whatwg] register*Handler and Web Intents
On Wed, Jul 25, 2012 at 7:20 PM, Ian Hickson i...@hixie.ch wrote: Our remaining discomfort here is with isIntentHandlerRegistered(), and for similar reasons to the fingerprinting qualities of isProtocolHandlerRegistered(). That is, we'd prefer that web content simply call registerProtocolHandler blindly, similar to what a declarative registration would do, and let the UA sort out whether the user ought to be shown any kind of registration UI. These is*Registered() methods don't expose anything that isn't already possible with cookies, so I propose that we just disable them if cookies are disabled, and say that clearing cookies should recommend clearing the registrations too. I don't like the fingerprinting potential here, and would prefer getting rid of all the is*Registered methods. Thinking about it as an analog to the declarative scheme, the page is basically telling the browser hey, I'm a service to which the browser can respond in many ways (ignore it, check existing registrations, write it down to be considered later, pop up an infobar, show a dialog if the call is accompanied by a user gesture, etc.) At the DAP meeting, we agreed to extend this system to include string-literal types, which provides a way to do good integration with microdata types. There we expect to do exact string matching, and it is true the eliminating wildcard types would bring these two type namespaces a bit closer. MIME is complex enough that it would still have to be treated separately, however. (Parameters and all that.) I'm not really sure I follow here. Could you elaborate? For microdata types, the matching would be exact. For MIME types, you need MIME-specific matching, since a service registered for text/html;a=bc=d should be delivered a payload with type=text/html;c=da=b. In public-web-intents, we anticipate important schema definitions which are independent of the API (such as this one) to end up in either best practices docs or additional addendum documents that describe how to use MIME types, or various microdata types, or interchange types made for other specs. On Thu, 24 May 2012, Greg Billock wrote: Some more concordance moves to make them more like different aspects of the same feature: * In registerContentHandler, t can be a space-separated list of MIME types for registerContentHandler. Do we need to support a space-separated list at all? When will the list be so long that it really makes sense to add that feature rather than just having three registrations back-to-back? (I have omittd a number of e-mails from this reply that gave suggestions that seemed reasonable and that have therefore been incorporated into the proposal above.) If nobody finds any egregious problems with the proposal above, I'll start speccing it as part of a rewrite of the register*Handler() section. (That section needs a rewrite into more imperative language anyway.) I'm not sure how to assess the options of using link or meta in place of intent. It looks to me like competing intuitions about the relative benefits and hazards of having something specific but new to the parser versus more overloading of existing generic terms. Would it make sense to consider this in the context of other declarative invocation possibilities? That is, if there are ways to invoke the feature without navigator.startActivity() or window.startIntent(), does that change the intuition about having a specific intent tag? As Ian has described, we can invoke these handlers with a href=protocol://x with the RPH form, and with any link with the RCH form. Analogous imperative calls can be done in Javascript which would cause the same dispatch pathway to be executed. But there is an option to explore more interesting navigational and declarative interactions that have come up in discussions with Alex Russell and other folks about this feature. For instance, you can imagine a generalization of these navigational forms that allow a registered handler to intercept navigations to a particular same-origin url space (i.e. http://example.com/app/*; or http://example.com/app/page?*;). This would enable app authors to have a high degree of control over their site's caching behavior while off-line, potentially helping with the functionality of appcache-style behavior. There are a couple of other related use cases, for example, having an existing open application or document be able to intercept self-navigations to re-activate itself.
Re: [whatwg] register*Handler and Web Intents
I also agree with Henri and James. I would be opposed to implementing the feature in WebKit the way it is currently proposed. The aesthetic benefit is not great enough to be worth the breakage. Consider in particular that the following proposed markup: intent action=edit type=image/png scheme=mailto href= title=Foo disposition= /intent could just as easily be: link intent action=edit type=image/png scheme=mailto href= title=Foo disposition= or: meta intent action=edit type=image/png scheme=mailto href= title=Foo disposition= Both of which are no more verbose and read about as well. - Maciej On Aug 6, 2012, at 8:11 AM, Henri Sivonen hsivo...@iki.fi wrote: On Fri, Aug 3, 2012 at 12:00 PM, James Graham jgra...@opera.com wrote: I agree with Henri that it is extremely worrying to allow aesthetic concerns to trump backward compatibility here. Letting aesthetic concerns trump backward compat is indeed troubling. It's also troubling that this even needs to be debated, considering that we're supposed to have a common understanding of the design principles and the design principles pretty clearly uphold backward compatibility over aesthetics. I would also advise strongly against using position in DOM to detect intents support; if you insist on adding a new void element I will strongly recommend that we add it to the parser asap to try and mitigate the above breakage, irrespective of whether our plans for the rest of the intent mechanism. I think the compat story for new void elements is so bad that we shouldn't add new void elements. (source gets away with being a void element, because the damage is limited by the /video or /audio end tag that comes soon enough after source.) I think we also shouldn't add new elements that don't imply body when appearing in in head. It's great that browsers have converged on the parsing algorithm. Let's not break what we've achieved to cater to aesthetics. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] register*Handler and Web Intents
On Mon, Aug 6, 2012 at 1:07 AM, rektide rekt...@voodoowarez.com wrote:
Hi,
Is there any ability to pass a MessageChannel Port in as an IntentSetting, or
out in the success handler? Is there any facility to allow multi-part
communications to an activity? For example, Sony does this in their Local UPnP
Service Discovery Web Intent's scheme:
http://www.w3.org/wiki/images/2/2e/V4_W3C_Web_Intents_-_Local_UPnP_Service_Discovery.pdf#page=15
Yes, in the web intents draft [1], the intention is that this object
implements web messaging semantics, including transferables.
[1] http://www.w3.org/TR/2012/WD-web-intents-20120626/
This is really the only way to get out of the one-shot request/response model,
which is extremely important to me, and the general versatility of this inter-
perability mechanism.
The callbacks given in the method, if provided, are invoked asynchronously
in reaction to the handler calling success() or failure() on the Intent
object. We would just allow one success or failure message per Intent,
for sanity's sake.
I'd far prefer a model not based up front on the one-shot model: a Intent
ought be a SharedWorker in terms of interactions with the page (although more
Intent-oriented in instantiation), crossed with the recent notion of Chrome's
Packaged App: a stand-alone contained experience. This is a radical turn I
would justify as due it's more general purpose interaction model. It also
invents far less: SharedWorkers just need some interface, and presto-chango,
we have the perfect Intents, rather than making an entirely new custom
suite of interaction models tailored to a more limited one shot use case.
I would be happy to make this proposal more concrete. Although I reference
Packaged App as a good model, the ultimate implementation could be merely
a new web browser page whose Window implements SharedWorker:
interface SharedWorker : EventTarget {
readonly attribute MessagePort port;
};
SharedWorker extends AbstractWorker;
interface AbstractWorker {
attribute EventHandler onerror;
};
If we want to stick on this current one shot model, I'd recommend chainable
Intents:
callback AnyCallback = void (any data, Intentable continuator);
interface Intentable {
void startIntent(IntentSettings intent,
optional AnyCallback success,
optional DOMStringCallback failure);
}
Window implements Intentable;
This is for this use multi-part case:
window.startIntent({action:control-point},function(cpData,myPanel){
myPanel.startIntent({action:play,data:{}})
})
Note that if the registration page does not have both of these the nested
startIntent will fail:
intent action=control-point scheme=? title=RCA Control Panel/
intent action=play scheme=? title=Play on RCA TV/
The desire I wish to express is creating a context which can be continued. The
explicit use of Intentable insures that only the previous handler will be
able to handle the new request. I'd seek a more formal mechanic to officially
carry on the continuation: informally, cpData could hold a token which could
be passed into the data of myPanel's play startIntent, but this ad-hoc
continuation is a weak way of being able to hold a reasonable conversation.
In parting, I wish to thank Sony for showing the utmost pragmatism in their
design. I appreciate their two approaches to this problem, and for showing
what a real service discovery use case looks like.
Fair regards, delighted to see this topic being talked about, please let me
know how I can aid,
rektide
Re: [whatwg] register*Handler and Web Intents
Hi,
Is there any ability to pass a MessageChannel Port in as an IntentSetting, or
out in the success handler? Is there any facility to allow multi-part
communications to an activity? For example, Sony does this in their Local UPnP
Service Discovery Web Intent's scheme:
http://www.w3.org/wiki/images/2/2e/V4_W3C_Web_Intents_-_Local_UPnP_Service_Discovery.pdf#page=15
This is really the only way to get out of the one-shot request/response model,
which is extremely important to me, and the general versatility of this inter-
perability mechanism.
The callbacks given in the method, if provided, are invoked asynchronously
in reaction to the handler calling success() or failure() on the Intent
object. We would just allow one success or failure message per Intent,
for sanity's sake.
I'd far prefer a model not based up front on the one-shot model: a Intent
ought be a SharedWorker in terms of interactions with the page (although more
Intent-oriented in instantiation), crossed with the recent notion of Chrome's
Packaged App: a stand-alone contained experience. This is a radical turn I
would justify as due it's more general purpose interaction model. It also
invents far less: SharedWorkers just need some interface, and presto-chango,
we have the perfect Intents, rather than making an entirely new custom
suite of interaction models tailored to a more limited one shot use case.
I would be happy to make this proposal more concrete. Although I reference
Packaged App as a good model, the ultimate implementation could be merely
a new web browser page whose Window implements SharedWorker:
interface SharedWorker : EventTarget {
readonly attribute MessagePort port;
};
SharedWorker extends AbstractWorker;
interface AbstractWorker {
attribute EventHandler onerror;
};
If we want to stick on this current one shot model, I'd recommend chainable
Intents:
callback AnyCallback = void (any data, Intentable continuator);
interface Intentable {
void startIntent(IntentSettings intent,
optional AnyCallback success,
optional DOMStringCallback failure);
}
Window implements Intentable;
This is for this use multi-part case:
window.startIntent({action:control-point},function(cpData,myPanel){
myPanel.startIntent({action:play,data:{}})
})
Note that if the registration page does not have both of these the nested
startIntent will fail:
intent action=control-point scheme=? title=RCA Control Panel/
intent action=play scheme=? title=Play on RCA TV/
The desire I wish to express is creating a context which can be continued. The
explicit use of Intentable insures that only the previous handler will be
able to handle the new request. I'd seek a more formal mechanic to officially
carry on the continuation: informally, cpData could hold a token which could
be passed into the data of myPanel's play startIntent, but this ad-hoc
continuation is a weak way of being able to hold a reasonable conversation.
In parting, I wish to thank Sony for showing the utmost pragmatism in their
design. I appreciate their two approaches to this problem, and for showing
what a real service discovery use case looks like.
Fair regards, delighted to see this topic being talked about, please let me
know how I can aid,
rektide
Re: [whatwg] register*Handler and Web Intents
On Fri, Aug 3, 2012 at 12:00 PM, James Graham jgra...@opera.com wrote: I agree with Henri that it is extremely worrying to allow aesthetic concerns to trump backward compatibility here. Letting aesthetic concerns trump backward compat is indeed troubling. It's also troubling that this even needs to be debated, considering that we're supposed to have a common understanding of the design principles and the design principles pretty clearly uphold backward compatibility over aesthetics. I would also advise strongly against using position in DOM to detect intents support; if you insist on adding a new void element I will strongly recommend that we add it to the parser asap to try and mitigate the above breakage, irrespective of whether our plans for the rest of the intent mechanism. I think the compat story for new void elements is so bad that we shouldn't add new void elements. (source gets away with being a void element, because the damage is limited by the /video or /audio end tag that comes soon enough after source.) I think we also shouldn't add new elements that don't imply body when appearing in in head. It's great that browsers have converged on the parsing algorithm. Let's not break what we've achieved to cater to aesthetics. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] register*Handler and Web Intents
On 08/02/2012 06:57 PM, Ian Hickson wrote: But now consider the short-term cost of adding an element to the head. All it does is make a few elements in the head leak to the body. The page still works fine in legacy UAs (none of the elements only work in the head). But it will break any scripts or selectors that depend on position in the DOM. For that reason I expect many pages that include intents won't work fine in UAs that don't have parser support. I agree with Henri that it is extremely worrying to allow aesthetic concerns to trump backward compatibility here. I would also advise strongly against using position in DOM to detect intents support; if you insist on adding a new void element I will strongly recommend that we add it to the parser asap to try and mitigate the above breakage, irrespective of whether our plans for the rest of the intent mechanism.
Re: [whatwg] register*Handler and Web Intents
On Thu, Jul 26, 2012 at 5:20 AM, Ian Hickson i...@hixie.ch wrote: Thus, I propose a parallel mechanism in the form of an empty element that goes in the head: intent action=edit intent action, e.g. open or edit, default share type=image/png MIME type filter, default omitted, required if scheme omitted scheme=mailto Scheme filter, default omitted, required if type omitted href= Handler URL, default (current page) title=Foo Handler user-visible name, required attribute disposition=HandlerDisposition values, default overlay This is a severe violation of the Degrade Gracefully design principle. Adopting your proposal would mean that pages that include the intent element in head would parse significantly differently in browsers that predate the HTML parsing algorithm or in browsers that implement it in its current form. I believe that having the intent element break the parser out of head in browsers that don't contain the parser differences you implicitly propose would cause a lot of grief to Web authors and would hinder the adoption of this feature. My concerns could be addressed in any of these three ways: 1) Rename intent to link 2) Rename intent to meta 3) Make intent have an end tag and make it placed in body rather than head I prefer solution #1. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] register*Handler and Web Intents
On Thu, 2 Aug 2012, Henri Sivonen wrote: This is a severe violation of the Degrade Gracefully design principle. Adopting your proposal would mean that pages that include the intent element in head would parse significantly differently in browsers that predate the HTML parsing algorithm or in browsers that implement it in its current form. I believe that having the intent element break the parser out of head in browsers that don't contain the parser differences you implicitly propose would cause a lot of grief to Web authors and would hinder the adoption of this feature. My concerns could be addressed in any of these three ways: 1) Rename intent to link 2) Rename intent to meta 3) Make intent have an end tag and make it placed in body rather than head I'm pretty sure the short-term pain of introducing a new head element would be far lower than the long-term pain of either of those three solutions. _Far_ lower. link and meta already have tons of overloaded behaviours, but none of them come close to matching the set of attributes intent would need. So we'd be overloading them with yet another mechanism, further increasing author confusion for those elements forever. Having intent have an end tag is really ugly, since the element has no contents. We'd be forever requiring that authors add this dummy end tag that doesn't do anything, yet if forgotten causes all kinds of trouble in the DOM. Authors would try putting things inside it, further confusing matters. But now consider the short-term cost of adding an element to the head. All it does is make a few elements in the head leak to the body. The page still works fine in legacy UAs (none of the elements only work in the head). The intent works fine in new browsers, isn't confusing, doesn't have any random vestigial end tags. The only difference is that in legacy UAs, some elements happen to be in the body instead of the head, but that's hardly a big hardship -- and it's easy to work around, you just put the intent elements last in the head, and then you can even use their position in the DOM as a way to detect support. I really am unconvinced that this is a lot of grief. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] register*Handler and Web Intents
On Wed, Jul 25, 2012 at 10:20 PM, Ian Hickson i...@hixie.ch wrote:
Having carefully studied the Mozilla Web Activities proposal, the Web
Intents draft, the register*Handler APIs, and to a lesser extent the
dispatch mechanisms in existing operating systems (desktop and mobile) and
the piles of advocacy on teh subject on the Web, I've tried to come up
with a concrete proposal for merging all of them into a coherent whole
that addresses the limited use cases that are of most interest.
Overall, this proposal mainly draws from the following sources:
- For the handling mechanimsm, it's basically directly based on the
Mozilla System Message Handler mechanism.
- For the dispatch mechanism, it is based mainly on the Web Intents
draft.
- For the registration mechanism, it's based on extending the
register*Handler APIs consistently.
However, I have attempted to simplify the proposal from its sources of
inspiration, where that seemed possibly without sacrificing key use cases.
The overall design is that there are URLs that can handle particular
messages, herein called intents (mostly because that's what Web developers
seem to have adopted as the term already).
These intents are indications that the user, or the system on behalf of
the user, wants the application to do something or other.
For example: please open this PDF, please share these four images,
please be aware that it is now the time you asked to be awoken at,
please allow the user to compose an e-mail to this address.
We want pages to be able to handle intents promptly upon being opened.
This puts certain constraints on the design that are explained in detail
in the Mozilla System Intents thread:
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/o8bkwx0EtmM
This leads therefore to the first part of the concrete proposal:
partial interface Window {
void setIntentHandler(DOMString action, IntentCallback callback);
set generally implies only one value for a given key - is this the case?
Or is this more like add—where I can add an arbitrary number of handlers
to for any given action.
boolean hasPendingIntent(DOMString action);
}
callback IntentCallback = void (Intent intent);
Is there any way this can be re-thought that avoids adding more API to the
global object? What about using Intent as the global namespace object and
hanging the Intent API there. The Intent object below would need to be
renamed—why not Intention, it works nicely in discussion/explanation as
well: Intent handlers receive an Intention object as the sole argument
when the UA asynchronously calls the handler...
When a page is loaded, it registers its intent handler callback using
setIntentHandler(), and as soon as that happens, the UA asynchronously
calls the handler.
The Intent object itself just needs to describe what the page is being
asked to do. For this, I borrowed freely from all the proposals mentioned
above, and ended up with:
interface Intent {
See Intention above...
readonly attribute DOMString action,
Inclusion of an action property supports the arbitrary number of
handlers case (as well as the single delegation handler case.
readonly attribute DOMString type,
What piece of information is this?
readonly attribute any data,
void success(any data, optional sequenceTransferable transfer);
void failure(DOMString message);
Where do I define success and failure?
}
This is basically the data that needs to be sent from the application that
wants to initiate an intent, too:
dictionary IntentSettings {
DOMString action,
DOMString type,
What piece of information is this?
any data, // structured-cloned
sequenceTransferable transfer,
};
So how do we start an intent? Well, for intent handlers that are just
registered to handle URLs being loaded using certain schemes or that have
certain MIME types, you just use a link:
a href=web+customscheme:foo.../a
a href=file.customtype.../a
But more interestingly, to start one programmatically you would use a
startIntent() method:
partial interface Window {
void startIntent(IntentSettings intent,
Again, I hope you consider not making this a method of the global object.
(proposal below)
optional AnyCallback success,
optional DOMStringCallback failure);
I'm guessing this where the previously questioned success and failure are
defined?
What is a DOMStringCallback
}
callback AnyCallback = void (any data);
callback DOMStringCallback = void (DOMString message);
The callbacks given in the method, if provided, are invoked asynchronously
in reaction to the handler calling success() or failure() on the Intent
object. We would just allow one success or failure message per Intent,
for sanity's sake.
All of my notes above summarized would look like this...
Intent is a property
Re: [whatwg] register*Handler and Web Intents
Having carefully studied the Mozilla Web Activities proposal, the Web
Intents draft, the register*Handler APIs, and to a lesser extent the
dispatch mechanisms in existing operating systems (desktop and mobile) and
the piles of advocacy on teh subject on the Web, I've tried to come up
with a concrete proposal for merging all of them into a coherent whole
that addresses the limited use cases that are of most interest.
Overall, this proposal mainly draws from the following sources:
- For the handling mechanimsm, it's basically directly based on the
Mozilla System Message Handler mechanism.
- For the dispatch mechanism, it is based mainly on the Web Intents
draft.
- For the registration mechanism, it's based on extending the
register*Handler APIs consistently.
However, I have attempted to simplify the proposal from its sources of
inspiration, where that seemed possibly without sacrificing key use cases.
The overall design is that there are URLs that can handle particular
messages, herein called intents (mostly because that's what Web developers
seem to have adopted as the term already).
These intents are indications that the user, or the system on behalf of
the user, wants the application to do something or other.
For example: please open this PDF, please share these four images,
please be aware that it is now the time you asked to be awoken at,
please allow the user to compose an e-mail to this address.
We want pages to be able to handle intents promptly upon being opened.
This puts certain constraints on the design that are explained in detail
in the Mozilla System Intents thread:
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/o8bkwx0EtmM
This leads therefore to the first part of the concrete proposal:
partial interface Window {
void setIntentHandler(DOMString action, IntentCallback callback);
boolean hasPendingIntent(DOMString action);
}
callback IntentCallback = void (Intent intent);
When a page is loaded, it registers its intent handler callback using
setIntentHandler(), and as soon as that happens, the UA asynchronously
calls the handler.
The Intent object itself just needs to describe what the page is being
asked to do. For this, I borrowed freely from all the proposals mentioned
above, and ended up with:
interface Intent {
readonly attribute DOMString action,
readonly attribute DOMString type,
readonly attribute any data,
void success(any data, optional sequenceTransferable transfer);
void failure(DOMString message);
}
This is basically the data that needs to be sent from the application that
wants to initiate an intent, too:
dictionary IntentSettings {
DOMString action,
DOMString type,
any data, // structured-cloned
sequenceTransferable transfer,
};
So how do we start an intent? Well, for intent handlers that are just
registered to handle URLs being loaded using certain schemes or that have
certain MIME types, you just use a link:
a href=web+customscheme:foo.../a
a href=file.customtype.../a
But more interestingly, to start one programmatically you would use a
startIntent() method:
partial interface Window {
void startIntent(IntentSettings intent,
optional AnyCallback success,
optional DOMStringCallback failure);
}
callback AnyCallback = void (any data);
callback DOMStringCallback = void (DOMString message);
The callbacks given in the method, if provided, are invoked asynchronously
in reaction to the handler calling success() or failure() on the Intent
object. We would just allow one success or failure message per Intent,
for sanity's sake.
There is another way of starting an intent that I alluded to earlier: the
system can decide to dispatch one to a specific application. For example,
say an application has told the system (using some other API) that it
wants to be woken up at 07:00 to start playing a song (the user's alarm).
The system could dispatch an intent to the application using the mechanism
described above -- a system intent. To distinguish these from intents sent
by applications like airplay media, share picture, or open mailto:;,
one would use intent names prefixed by the string system-, for example,
system-alarm or system-nfc. The startIntent() method described above
therefore would, in this proposal, fail if the intent name started with
the substring system-.
All of this leads to the final piece of the puzzle, namely how to offer to
the user the ability to use a page as an intent handler. This is where the
existing register*Handler() methods come in. Taking a cue from Mozilla's
Web Activities proposal, I propose that we just use introduce methods for
the more generic intents system:
partial interface Navigator {
void registerProtocolHandler(DOMString scheme,
DOMString url, DOMString title, optional HandlerDisposition disposition);
void
Re: [whatwg] register*Handler and Web Intents
On Mon, Apr 02, 2012, Ian Hickson wrote: On Tue, 21 Feb 2012, Bjartur Thorlacius wrote: Windows Explorer (the file manager) does for example offer users to edit images upon right-click. I worry that if URI scheme handlers need not only take care of fetching but also of presentation, other actions than view will be unnecessarily hard to implement. Thus I figure retrieval and presentation must be separated. I don't really see how you would tell the browser what the action is. Users can select actions from context menus. The context menus are populated with the registered actions applicable for the context resource (filtered using the media type as a criterion). Example (just skip it if the above is clear): 1. An UA registers an intent (e.g. as found in an intent tag) 2. The UA embeds an image in an interactive document rendering for an user 3. The user opens a menu of actions pertaining to the image: * view (in original resolution) * share (on Flickr, via email, or using Bittorrent and an entry in The Pirate Bay) * edit (using either Photoshop or Gimp) 4. The user selects the edit menu, and thereunder Photoshop. The only attribute of network protocols that is of concern to most users is authentication. Many also care about encryption. Everything else is a technical detail that should be completely transparent, both to users and composers and viewers.
Re: [whatwg] register*Handler and Web Intents
On Fri, Apr 20, 2012 at 10:35 AM, Greg Billock gbill...@google.com wrote: Ian, My suggestion then would be to add an element similar to what you suggest, as well as an API similar to the existing one. The element could be something like: intent action=edit intent action, e.g. open or edit, default share type=image/png MIME type filter [1], default */* scheme=mailto Scheme filter [1] [2], default omitted href= Handler URL [2], default title=Foo Handler user-visible name, required attribute disposition= replace, new, or overlay, default overlay /intent [1] Only one of type= and scheme= is allowed. [2] scheme= is only allowed if href= contains %s. The API could be something like: void registerIntentHandler(DOMString action, DOMString type, DOMString url, DOMString title, DOMString disposition); DOMString isIntentHandlerRegistered(DOMString action, DOMString type, DOMString url); void unregisterIntentHandler(DOMString action, DOMString type, DOMString url); The disposition of registerContentHandler() and registerProtocolHandler() would always be replace. The /url/ argument of registerProtocolHandler() would not be allowed to contain %s. Here's a slightly altered suggestion. There'd be three imperative registration APIs and three permissible intent tag configurations: For web intents services: intent action=a type=t href=u ... (that is, both action and type required, scheme disallowed) void registerIntentHandler(a, t, u, ...); // and unregister for protocol handler services: intent scheme=s href=u ... (scheme required, action and type disallowed) void registerProtocolHandler(s, u, ...); // and unregister for content handler services: intent type=t href=u ... (type required, action and scheme disallowed) void registerContentHandler(t, u, ...); // and unregister intent tags without these permissible permutations of scheme|action|type attributes must be ignored. Some more concordance moves to make them more like different aspects of the same feature: * In registerContentHandler, t can be a space-separated list of MIME types for registerContentHandler. * Let's think through why we'd need to limit the dispositions of the case of RPH/RCH to disposition=replace. Can't we achieve backwards compatibility by specifying that those cases default to disposition=replace? This would make it straightforward to get a nice style of navigational interaction with web intents -- RPH-style invocations can be handled by any of the disposition transitions. (i.e. a mailto handler that did all it's work in an overlay, which is frequently very desirable). * Add a couple more legal permutations: adding 'action=view' to the RPH/RCH registration intent tags would mean that the payload gets delivered using web intents instead of through %s-substitution. The RPH/RCH APIs wouldn't expose this. (This is very useful for offline.) These aren't large modifications, and in general just increase forward compatibility by making it more clear how to get more functionality out of RPH/RCH by using declarative registration, and blending those cases into the intents-based implementation. -Greg
Re: [whatwg] register*Handler and Web Intents
Ian, As you can tell by the delay, we've (James Hawkins, Paul Kinlan, myself, others working on web intents for Chromium) been carefully reading your email and talking about the issues you bring up. I think we agree on most things, except for some small but important points. Considering RPH, RCH, and web intents all part of the same feature is a good plan. Even if the APIs are different (but parallel), having users able to think of them the same way is the right track. That is, the UA presentation of the features should be indistinguishable so that users can leverage familiarity with UI models of permission grants, manipulating defaults and installed options, and make correct attribution judgments easily when the features are used. On Mon, Apr 2, 2012 at 4:23 PM, Ian Hickson i...@hixie.ch wrote: Looking at the three features, it seems they break down as follows: a handler registered using registerContentHandler() triggers when a URL with a particular type is opened, and results in the URL being passed to another URL that is opened. a handler registered using registerProtocolHandler() triggers when a URL with a particular scheme is opened, and results in the URL being passed to another URL that is opened. a handler registered using Web Intents triggers when a method is invoked on another page, and results in a URL being opened and its JavaScript context being given the information passed to the method. For RPH, agreed that passing the URL is pretty much the only possible approach. For RCH, web intents allows us to do better than this: we can pass the content directly, in a Blob, rather than passing the URL, thus decoupling the service from the (possibly sensitive) URL from which the intent was triggered. That isn't always the right plan -- for feed URLs, passing the URL is an important feature enabler for a feed reader to deal with the content. Anyway, mostly pointing out that considering these together is a vehicle for more fine-grained control of the coupling. If anything, this intertwines them more closely. Thus we reach a point where we can describe all three as a common set of registration features: Agreed. This seems like a big win -- considering the registrations as different potential capabilities of the same service feels like a much simpler scenario for users. My suggestion then would be to add an element similar to what you suggest, as well as an API similar to the existing one. The element could be something like: intent action=edit intent action, e.g. open or edit, default share type=image/png MIME type filter [1], default */* scheme=mailto Scheme filter [1] [2], default omitted href= Handler URL [2], default title=Foo Handler user-visible name, required attribute disposition= replace, new, or overlay, default overlay /intent [1] Only one of type= and scheme= is allowed. [2] scheme= is only allowed if href= contains %s. The API could be something like: void registerIntentHandler(DOMString action, DOMString type, DOMString url, DOMString title, DOMString disposition); DOMString isIntentHandlerRegistered(DOMString action, DOMString type, DOMString url); void unregisterIntentHandler(DOMString action, DOMString type, DOMString url); The disposition of registerContentHandler() and registerProtocolHandler() would always be replace. The /url/ argument of registerProtocolHandler() would not be allowed to contain %s. A handler, once registered, would remain so until it was explicitly removed with unregisterIntentHandler() or removed by the user, as now for the other handler APIs; or, for registrations done with the declarative form, would remain until the user returns to the same page and the page returns a 200, 404, or 410 response (at which point it would be unregistered until such time as the intent elment is seen again, which could happen that very same page load). This all sounds good. The argument about unregistration is what really compels the imperative API, I think. Allowing (same-origin) pages to unregister handlers imperatively is key to reliably being able to not require a failed intent dispatch to a stale URL to unregister it. (Otherwise it'd be too easy to end up compelling the full registration-checking protocol on basically every page load to see if the absence of an intent tag means deregistration.) Another nicety is that RPH/RCH handlers can be invoked imperatively with navigator.startActivity. Our remaining discomfort here is with isIntentHandlerRegistered(), and for similar reasons to the fingerprinting qualities of isProtocolHandlerRegistered(). That is, we'd prefer that web content simply call registerProtocolHandler blindly, similar to what a declarative registration would do, and let the UA sort out whether the user ought to be shown any kind of registration UI. This does, however, impose some burden on clients to these systems. They'd
Re: [whatwg] register*Handler and Web Intents
On 04/03/2012 01:23 AM, Ian Hickson wrote: On Tue, 6 Dec 2011, Anne van Kesteren wrote: You could also have meta name=intent content=http://webintents.org/share image/* or some such. Splitting a string on spaces and using the result is not that hard and a common pattern. And seems like a much better alternative than changing the HTML parser. Trying to fit the registration components listed above into meta really doesn't work all that well, IMHO. meta name=viewport does that and is widely used AFAICT. On Tue, 6 Dec 2011, James Graham wrote: On Tue, 6 Dec 2011, Anne van Kesteren wrote: Especially changing the way head is parsed is hairy. Every new element we introduce there will cause a body to be implied before it in down-level clients. That's very problematic. Yes, I consider adding new elements to head to be very very bad for this reason. Breaking DOM consistency between supporting and non-supporting browsers can cause adding an intent to cause unrelated breakage (e.g. by changing document.body.firstChild). That is true, but adding this to the body seems weird too. How bad would that be? Do we expect a lot of breakage? Can't we simply assume websites would use the programmatic registration if the declarative one doesn't work/break some old browsers? On Tue, 6 Dec 2011, James Hawkins wrote: Originally we envisioned using a self-closing tag placed in head for the intent tag; however, we're now leaning towards not using self-closing and having the tag be placed in the body with fallback content, e.g., to install an extension to provide similar functionality. intent action=webintents.org/share Click here to install our extension that implements sharing! /intent What are your thoughts on this route? How common will fallback be on the short term and on the long term? I think the fallback is quite useless here. I don't think wildcard matching really makes sense. In particular, I'm not aware of any service that can honestly say it supports image/*, or indeed any other topleveltype/*. Doesn't @accept on input allows image/*, video/*, audio/*? We should at least accept those values. But maybe it would be safe to allow foo/* if a service and client would be connected only if they both marked they foo/* as a type? On Fri, 16 Dec 2011, Paul Kinlan wrote: We didn't want to add additional attributes to the meta tag or link tag just for intents, this seems to open up the flood gates for future platform features to also extend the meta syntax, the meta element then just becomes a dumping ground. That's not a big concern, so long as the semantics make sense. With intent registration, I'm not sure they do. e.g. with link href= you'd want to be able to register a URL with a %s segment for content/protocol handlers, but that's no longer a valid URL, so it's weird to use href= which currently requires a valid URL. Similarly, using type= to mean the filter rather than the type of the content at the href= URL would mean the type= attribute has a different meaning based on context. Similarly, we have an action= attribute on link that defines the disposition, but it has different values than what we're talking about here, so it would be weird to reuse it, and would be weird not to. meta is also a weird case because we'd basically be reusing the element but none of the attributes, and it already has three different roles. AFAIUI, link is far from ideal for what we want. IMO, meta would match quite well our needs. We could put all the information in @content like meta name='viewport' is doing. However, IIUIC, we can have only one meta with a given @name which means a page will not be able to register declaratively more than one intent. Otherwise, we could come with a very complex syntax to allow more than one declaration in @content. On Wed, 15 Feb 2012, James Hawkins wrote: We, the designers of the Web Intents draft API, have always seen Web Intents as a superset of the functionality provided by registerProtocolHandler (RPH) and registerContentHandler (RCH). To follow this to the logical conclusion, we should be able to provide functionally equivalent counterparts to RPH/RCH in Web Intents. This proposal provides a means of deprecating RPH/RCH, replacing this functionality with equivalent functionality from Web Intents. I don't think it makes sense to deprecate them. We should design intents to incorporate them, not deprecate them. Given that Web Intents would deprecate/supersede RPH and RCH, I wonder why we should bother incorporating them. - Using URLs as intents, especially for the default intents, is overly verbose. I highly recommend just having a wiki page be a registry of widely used intents, and saying that if people want specialised ones for their own communities, they can then use URLs, but otherwise it's fine to just use simple identifiers like edit or share, so long as they are
Re: [whatwg] register*Handler and Web Intents
On Tue, 17 Apr 2012 17:11:52 +0100, Mounir Lamouri mou...@lamouri.fr wrote: Trying to fit the registration components listed above into meta really doesn't work all that well, IMHO. meta name=viewport does that and is widely used AFAICT. It's used because it has important functionality and sensible syntax (CSS @viewport) is not widely supported yet. However, the design and usability of meta viewport is terrible. You'll find a lot of pages on the web that get , vs ; wrong in the meta content. -- regards, Kornel Lesiński
