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
Re: Adding Web Intents to the Webapps WG deliverables
On Sun, 25 Sep 2011, John J Barton wrote: On Thu, Sep 22, 2011 at 2:36 PM, Ian Hickson i...@hixie.ch wrote: There's no difference between two people coming up with the name foo and two people coming up with the name http://webintents.org/foo;, unless you're saying you're confident that people won't use the prefix the spec uses for its verbs for their verbs. I don't think this claim makes sense. As a developer I have no way to know if 'foo' is used by anyone else on the Internet, but it would be trivial to check http://webintents.org/foo;. How would you check if I'm using http://webintents.org/foo? 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 I believe all of these examples have one or more central name controls. The rel example in particular provides a counter example to using simple uncontrolled verbs: http://microformats.org/wiki/existing-rel-values Multiple naming authorities, layered on wiki, and still messy. Why are they more messy than DNS? A verb on its own will imply that it is a web intents verb managed by the webintents project and all the documentation for that will live under webintents, which means we would then need to think about standardisation and stewardship for the entire namespace. I don't see why. Just have a wiki page that people can list their verbs on and then point to their documentation. A wiki is not comparable to the controlled naming systems in the four examples you give above. rel= uses a wiki. Element names uses nothing at all; anyone can invent a new one, there's no central authority. A wiki is a free for all that works great when there is no money involved. A Web system involving 'share' along with images, audio, and video will have money involved. I don't see why having money involved will make any difference. Could you elaborate? Why has this problem not occured with element names or rel= values? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Adding Web Intents to the Webapps WG deliverables
On Sep 20, 2011, at 19:09 , Ian Fette (イアンフェッティ) wrote: If you can guarantee me that the other browsers will join DAP then let's talk (namely MSFT who just announced a similar spec for Metro, and it would be very important to get their input here.) Wish granted! Let's talk then. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Adding Web Intents to the Webapps WG deliverables
[ + DAPI Chairs and Team Contact ] Hi Ian, All - for now, I think it is OK to use public-webapps for *technical* discussions regarding James' proposal. Let's plan to continue the charter-related part of this discussion during WebApp's TPAC meeting. I added it to the Monday October 31 13:00-15:00 time slot: http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31 (FYI, Robin added a Merge DAP into WebApps, proposed by Robin Berjon topic ins this same time slot.) -ArtB On 10/4/11 1:22 PM, ext Ian Fette (イアンフェッティ) wrote: Circling back to the original topic, it seems like there's a good amount of interest and opinions, and that the spec would probably benefit from the input of the people in this WG, especially since multiple platforms are all shipping something similar in approach (android intents, contracts in win8 and whatever implication that has for Metro/IE, and the proposed web intents). This is good to see. -Ian On Thu, Sep 29, 2011 at 11:34 AM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: Top posting: in web messaging, we typically set an origin property on events and authors are expected to check that property. Are your concerns addressed by that practice? It is an added step, an added nuance. And developers may neglect it. But, if they are neglecting origin, they are just plain leaving security holes. On Sep 28, 2011, at 12:09 PM, Adrienne Porter Felt a...@berkeley.edu mailto:a...@berkeley.edu wrote: Android developers chronically misunderstand and misuse Android Intents, and these mistakes lead to security bugs. To illustrate how prevalent the confusion is, Erika Chin and I found that 9 of 20 popular Android apps (45%!) contain security vulnerabilities due to misusing Intents. I've also found these same types of bugs in Google-produced Android applications (the default ones that ship as built-in apps). I posted examples details of two real-world applications that exhibit these vulnerabilities: http://www.adrienneporterfelt.com/blog/?p=313. It's my hope that Web Intents can be designed to prevent developers from making the same mistakes. There are two common types of errors: 1) Android Intents can be used for both inter- and intra-application communication, and developers don't know the difference. A canonical accident occurs when a developer creates a unique action string like foo.bar.xyz and uses it for internal communication. The problem is that any other application can register for the same action string, even if it's supposedly hard to guess. This introduces two security bugs. (1) The component that receives foo.bar.xyz has been unintentionally made public, since anyone can send that action string to it. (2) Another application could register to receive foo.bar.xyz and steal any data associated with it, or simply gain the user's attention away from the original app. 2) The Android OS sends Intents to applications as notifications. Developers register components to receive these system Intents. By default, registering for a system Intent makes a component public. Developers don't realize that these components become public by default, so they don't check that the Intent was really sent by the OS. I have two suggestions to prevent these same errors from appearing in Web Intents: 1) Developers need to be discouraged from using Web Intents for internal application communication. One way to do this is to make it so that Web Intents are only delivered after the user selects a service in a browser popup window. (Nothing hidden in the background!) This would be annoying for intra-application communication, so I think developers would avoid it. 2) If a developer registers to receive a Web Intent from the browser (like for a system notification), that component should NOT be invocable by any other application unless it's registered for a second Intent as well. Adrienne
Re: Adding Web Intents to the Webapps WG deliverables
Arthur Barstow wrote: [ + DAPI Chairs and Team Contact ] Hi Ian, All - for now, I think it is OK to use public-webapps for *technical* discussions regarding James' proposal. Let's plan to continue the charter-related part of this discussion during WebApp's TPAC meeting. I added it to the Monday October 31 13:00-15:00 time slot: http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31 (FYI, Robin added a Merge DAP into WebApps, proposed by Robin Berjon topic ins this same time slot.) Robin is proposing an interesting idea. Perhaps we could form a sub-group in WebApps to work on Device related features. Exactly what device-related features get picked up would be at the discretion of those involved. The options at this point are a.) None b.) some or c.) all of the deliverables of DAP transferring over to a group that has more comprehensive IP exclusion coverage. It would be a lot easier if everyone joined the DAP WG instead but I feel we're going nowhere with that approach. - Rich
Re: Adding Web Intents to the Webapps WG deliverables
Circling back to the original topic, it seems like there's a good amount of interest and opinions, and that the spec would probably benefit from the input of the people in this WG, especially since multiple platforms are all shipping something similar in approach (android intents, contracts in win8 and whatever implication that has for Metro/IE, and the proposed web intents). This is good to see. -Ian On Thu, Sep 29, 2011 at 11:34 AM, Charles Pritchard ch...@jumis.com wrote: Top posting: in web messaging, we typically set an origin property on events and authors are expected to check that property. Are your concerns addressed by that practice? It is an added step, an added nuance. And developers may neglect it. But, if they are neglecting origin, they are just plain leaving security holes. On Sep 28, 2011, at 12:09 PM, Adrienne Porter Felt a...@berkeley.edu wrote: Android developers chronically misunderstand and misuse Android Intents, and these mistakes lead to security bugs. To illustrate how prevalent the confusion is, Erika Chin and I found that 9 of 20 popular Android apps (45%!) contain security vulnerabilities due to misusing Intents. I've also found these same types of bugs in Google-produced Android applications (the default ones that ship as built-in apps). I posted examples details of two real-world applications that exhibit these vulnerabilities: http://www.adrienneporterfelt.com/blog/?p=313 http://www.adrienneporterfelt.com/blog/?p=313. It's my hope that Web Intents can be designed to prevent developers from making the same mistakes. There are two common types of errors: 1) Android Intents can be used for both inter- and intra-application communication, and developers don't know the difference. A canonical accident occurs when a developer creates a unique action string like foo.bar.xyz and uses it for internal communication. The problem is that any other application can register for the same action string, even if it's supposedly hard to guess. This introduces two security bugs. (1) The component that receives foo.bar.xyz has been unintentionally made public, since anyone can send that action string to it. (2) Another application could register to receive foo.bar.xyz and steal any data associated with it, or simply gain the user's attention away from the original app. 2) The Android OS sends Intents to applications as notifications. Developers register components to receive these system Intents. By default, registering for a system Intent makes a component public. Developers don't realize that these components become public by default, so they don't check that the Intent was really sent by the OS. I have two suggestions to prevent these same errors from appearing in Web Intents: 1) Developers need to be discouraged from using Web Intents for internal application communication. One way to do this is to make it so that Web Intents are only delivered after the user selects a service in a browser popup window. (Nothing hidden in the background!) This would be annoying for intra-application communication, so I think developers would avoid it. 2) If a developer registers to receive a Web Intent from the browser (like for a system notification), that component should NOT be invocable by any other application unless it's registered for a second Intent as well. Adrienne
Re: Adding Web Intents to the Webapps WG deliverables
Android developers chronically misunderstand and misuse Android Intents, and these mistakes lead to security bugs. To illustrate how prevalent the confusion is, Erika Chin and I found that 9 of 20 popular Android apps (45%!) contain security vulnerabilities due to misusing Intents. I've also found these same types of bugs in Google-produced Android applications (the default ones that ship as built-in apps). I posted examples details of two real-world applications that exhibit these vulnerabilities: http://www.adrienneporterfelt.com/blog/?p=313. It's my hope that Web Intents can be designed to prevent developers from making the same mistakes. There are two common types of errors: 1) Android Intents can be used for both inter- and intra-application communication, and developers don't know the difference. A canonical accident occurs when a developer creates a unique action string like foo.bar.xyz and uses it for internal communication. The problem is that any other application can register for the same action string, even if it's supposedly hard to guess. This introduces two security bugs. (1) The component that receives foo.bar.xyz has been unintentionally made public, since anyone can send that action string to it. (2) Another application could register to receive foo.bar.xyz and steal any data associated with it, or simply gain the user's attention away from the original app. 2) The Android OS sends Intents to applications as notifications. Developers register components to receive these system Intents. By default, registering for a system Intent makes a component public. Developers don't realize that these components become public by default, so they don't check that the Intent was really sent by the OS. I have two suggestions to prevent these same errors from appearing in Web Intents: 1) Developers need to be discouraged from using Web Intents for internal application communication. One way to do this is to make it so that Web Intents are only delivered after the user selects a service in a browser popup window. (Nothing hidden in the background!) This would be annoying for intra-application communication, so I think developers would avoid it. 2) If a developer registers to receive a Web Intent from the browser (like for a system notification), that component should NOT be invocable by any other application unless it's registered for a second Intent as well. Adrienne
Re: Adding Web Intents to the Webapps WG deliverables
Hi, Thanks for the synopsis of the issues. We didn't want to specifically exclude it from intra-app communication, but the result is like you mention actions can be invoked that they might not have thought would be possible or apps can replace - currently the system requires user intervention to select the service. For this intra-app comms when the developer knows the exact intent we are discussing explicit intents (the app developer knows the intent the developer should use). Developers will have to trust the data as from an untrusted source - unless we have some whitelist part of the API which the UA would restrict to a subset of domains that the service specifies. (but we haven't discussed this) System generated broadcast intents are out of the scope of web intents at the moment, however system generated intents are not, the UA could trigger a share for instance if the vendor had put a native menu item in to the browser etc. It would be up to the UA to decide who could invoke specific intents, currently in the spec we are not defining any intents directly so we are not planning on telling the vendors to restrict access to certain ones - but it could defiantly be managed. P On Wed, Sep 28, 2011 at 8:09 PM, Adrienne Porter Felt a...@berkeley.eduwrote: Android developers chronically misunderstand and misuse Android Intents, and these mistakes lead to security bugs. To illustrate how prevalent the confusion is, Erika Chin and I found that 9 of 20 popular Android apps (45%!) contain security vulnerabilities due to misusing Intents. I've also found these same types of bugs in Google-produced Android applications (the default ones that ship as built-in apps). I posted examples details of two real-world applications that exhibit these vulnerabilities: http://www.adrienneporterfelt.com/blog/?p=313. It's my hope that Web Intents can be designed to prevent developers from making the same mistakes. There are two common types of errors: 1) Android Intents can be used for both inter- and intra-application communication, and developers don't know the difference. A canonical accident occurs when a developer creates a unique action string like foo.bar.xyz and uses it for internal communication. The problem is that any other application can register for the same action string, even if it's supposedly hard to guess. This introduces two security bugs. (1) The component that receives foo.bar.xyz has been unintentionally made public, since anyone can send that action string to it. (2) Another application could register to receive foo.bar.xyz and steal any data associated with it, or simply gain the user's attention away from the original app. 2) The Android OS sends Intents to applications as notifications. Developers register components to receive these system Intents. By default, registering for a system Intent makes a component public. Developers don't realize that these components become public by default, so they don't check that the Intent was really sent by the OS. I have two suggestions to prevent these same errors from appearing in Web Intents: 1) Developers need to be discouraged from using Web Intents for internal application communication. One way to do this is to make it so that Web Intents are only delivered after the user selects a service in a browser popup window. (Nothing hidden in the background!) This would be annoying for intra-application communication, so I think developers would avoid it. 2) If a developer registers to receive a Web Intent from the browser (like for a system notification), that component should NOT be invocable by any other application unless it's registered for a second Intent as well. Adrienne -- 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
Re: Adding Web Intents to the Webapps WG deliverables
Top posting: in web messaging, we typically set an origin property on events and authors are expected to check that property. Are your concerns addressed by that practice? It is an added step, an added nuance. And developers may neglect it. But, if they are neglecting origin, they are just plain leaving security holes. On Sep 28, 2011, at 12:09 PM, Adrienne Porter Felt a...@berkeley.edu wrote: Android developers chronically misunderstand and misuse Android Intents, and these mistakes lead to security bugs. To illustrate how prevalent the confusion is, Erika Chin and I found that 9 of 20 popular Android apps (45%!) contain security vulnerabilities due to misusing Intents. I've also found these same types of bugs in Google-produced Android applications (the default ones that ship as built-in apps). I posted examples details of two real-world applications that exhibit these vulnerabilities: http://www.adrienneporterfelt.com/blog/?p=313. It's my hope that Web Intents can be designed to prevent developers from making the same mistakes. There are two common types of errors: 1) Android Intents can be used for both inter- and intra-application communication, and developers don't know the difference. A canonical accident occurs when a developer creates a unique action string like foo.bar.xyz and uses it for internal communication. The problem is that any other application can register for the same action string, even if it's supposedly hard to guess. This introduces two security bugs. (1) The component that receives foo.bar.xyz has been unintentionally made public, since anyone can send that action string to it. (2) Another application could register to receive foo.bar.xyz and steal any data associated with it, or simply gain the user's attention away from the original app. 2) The Android OS sends Intents to applications as notifications. Developers register components to receive these system Intents. By default, registering for a system Intent makes a component public. Developers don't realize that these components become public by default, so they don't check that the Intent was really sent by the OS. I have two suggestions to prevent these same errors from appearing in Web Intents: 1) Developers need to be discouraged from using Web Intents for internal application communication. One way to do this is to make it so that Web Intents are only delivered after the user selects a service in a browser popup window. (Nothing hidden in the background!) This would be annoying for intra-application communication, so I think developers would avoid it. 2) If a developer registers to receive a Web Intent from the browser (like for a system notification), that component should NOT be invocable by any other application unless it's registered for a second Intent as well. Adrienne
Re: Adding Web Intents to the Webapps WG deliverables
On Tue, 20 Sep 2011 16:04:29 +0200, Ian Fette (イアンフェッティ) ife...@google.com wrote: With all due respect, I think that if we have to re-charter or create a new working group each time a new API comes up we are all doomed. The overhead of creating and monitoring so many WGs is not appealing to many of us. Agreed - but at the same time if people start doing work that others are doing in another group, so they can do it with different people, we are all doomed. It is generally not a helpful way to get to a common standard. There is a group where the work you're interested in was already agreed as a deliverable. Which to some extent suggests this isn't a new API, it's Yet another API for doing something people knew they wanted to do. Reading this discussion and understanding the issue multiplied out over the people who effectively have to follow the discussion seems far more process overhead than you and MS just joining that group. Even if MS doesn't join, they can (and with all the rest of webapps will be invited to) comment and make an IPR commitment. And as noted, discussing on the same list doesn't guarantee attention from the other subscribers anyway. We are unlikely to stop you holding discussion here, but it would appear that it makes more sense to do it in a group which is already chartered to produce the deliverable. So with all due respect, I suggest that joining DAP and doing the work is an efficient way forward, while carrying on a process discussion here is sidetracking a lot of people whose time could otherwise be spent making technical progress on something. Part of the value of W3C standards, as compared to random spec proposals from a vendor or three, comes from a process that gives many kinds of stakeholders confidence in what that means. Chartering a group with a reasonable scope definition and then doing that work there is part of the way that process works. You could always ask Google's W3C Advisory Committee representative T V Raman to raise the process discussion to the AC forum, where it is directly in scope. The point of this group, DAP, and other WGs is to focus on doing their chartered technical work. cheers On Tue, Sep 20, 2011 at 6:55 AM, Robin Berjon ro...@berjon.com wrote: Hi James, thanks for bringing this forward, it is indeed a very interesting approach. On Sep 19, 2011, at 22:27 , James Hawkins wrote: I've read through the Webapps charter, and I believe Web Intents fits the goals and scope of the WG. It does fit the goal and scope, but then most web client technology does ;) Where you may run into issues is that it does not fit in the deliverables list. Since that is what members makes their IP commitment on, a new deliverable of non-negligible content might require rechartering. Last time we did that, it wasn't very pleasant. Thankfully, there is already a group that was chartered with Intents (or, in the poetic phrasing of charters, with an API that allows web applications to register themselves as handlers/providers based on data string identifiers and an API that enables other web applications to discover these handlers/providers and gain permission to interact with them — but Intents is what that means): the Device APIs group, http://www.w3.org/2011/07/DeviceAPICharter. It'd save a lot on the bureaucracy and allow us all to just go straight to work. We'd certainly be happy to accept your draft input. The new DAP is meant to be completely flexible in how it is organised. Notably, if you prefer to conduct work on this spec without necessarily getting all the email from the rest of the group we can setup a dedicated Task Force with its own mailing list and chair (if there's a volunteer, otherwise I'll do it). TFs can decide whether they want to have telcons or not. -- Robin Berjon - http://berjon.com/ - @robinberjon -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Adding Web Intents to the Webapps WG deliverables
On Thu, Sep 22, 2011 at 2:36 PM, Ian Hickson i...@hixie.ch wrote: There's no difference between two people coming up with the name foo and two people coming up with the name http://webintents.org/foo;, unless you're saying you're confident that people won't use the prefix the spec uses for its verbs for their verbs. I don't think this claim makes sense. As a developer I have no way to know if 'foo' is used by anyone else on the Internet, but it would be trivial to check http://webintents.org/foo;. 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 I believe all of these examples have one or more central name controls. The rel example in particular provides a counter example to using simple uncontrolled verbs: http://microformats.org/wiki/existing-rel-values Multiple naming authorities, layered on wiki, and still messy. A verb on its own will imply that it is a web intents verb managed by the webintents project and all the documentation for that will live under webintents, which means we would then need to think about standardisation and stewardship for the entire namespace. I don't see why. Just have a wiki page that people can list their verbs on and then point to their documentation. A wiki is not comparable to the controlled naming systems in the four examples you give above. A wiki is a free for all that works great when there is no money involved. A Web system involving 'share' along with images, audio, and video will have money involved. I think the intent names need a controlled namespace, either centralized like your examples or decentralized as in the original proposal. URLs need not be the format. Note the Firefox extension developers use domain@name format for unique ids. jjb
Re: Adding Web Intents to the Webapps WG deliverables
On Thu, 22 Sep 2011, John J Barton wrote: On Thu, Sep 22, 2011 at 5:22 PM, Charles Pritchard ch...@jumis.com wrote: I don't see why. Just have a wiki page that people can list their verbs on and then point to their documentation. I agree here. The standard is sufficient for stewardship. Why won't I create a bot that fills with wiki with a dictionary's worth of verbs point to my important intent: making money on advertising? My own personal single-point of control. Oh, you think your bot is faster than mine? We'll see about that! Oh, the wiki domain owners stepped in? Set up a committee to approve changes? Censorship! Politics! Slowness! Changing the wiki would do nothing here, it's just documentation, and does not affect the implementations. So this is a non-issue. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Adding Web Intents to the Webapps WG deliverables
On 2011-09-23 01:40, Tab Atkins Jr. wrote: On Thu, Sep 22, 2011 at 3:28 PM, James Hawkinsjhawk...@google.com wrote: 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. URLs are really, really not a good namespacing mechanism, because URLs are not names in practice. Names are compared with string-equality, generally. URLs are compared as URLs, which is a lot crazier. Is ... No, they are not. It depends on context. http://dev.twitter.com/tweet; the same action as http://dev.twitter.com/tweet/;? What about https://dev.twitter.com/tweet; or //dev.twitter.com/tweet or /tweet (assume this last one is on a page within dev.twitter.com)? Yes, a spec needs to specify that. There's a decent chance that all of these are considered the same url by devs, and devs will probably attempt to use them. I haven't even mentioned yet the presence/absence of www in urls. Contrary to what you say, I don't see anybody confused by URI comparison when URIs are used as identifiers. ... Best regards, Julian
Re: Adding Web Intents to the Webapps WG deliverables
On 9/23/11 4:13 PM, Julian Reschke wrote: Contrary to what you say, I don't see anybody confused by URI comparison when URIs are used as identifiers. If I had $1 for every time I wrote xmlns=http://www.w3.org/1999/xhtml/; and $10 for every time I told someone their page was broken because they'd done that, I'd get myself a vacation package... -Boris
Re: Adding Web Intents to the Webapps WG deliverables
On Fri, Sep 23, 2011 at 1:13 PM, Julian Reschke julian.resc...@gmx.de wrote: There's a decent chance that all of these are considered the same url by devs, and devs will probably attempt to use them. I haven't even mentioned yet the presence/absence of www in urls. Contrary to what you say, I don't see anybody confused by URI comparison when URIs are used as identifiers. It's hard to say willful blindness without sounding mean, so I'll just point and nod at Boris' email. ~TJ
Re: Adding Web Intents to the Webapps WG deliverables
On 9/23/11 5:20 PM, Julian Reschke wrote: If I had $1 for every time I wrote xmlns=http://www.w3.org/1999/xhtml/; and $10 for every time I told someone their page was broken because they'd done that, I'd get myself a vacation package... Namespace names are things I copy from templates and never type from memory. Sure. So your typical author goes to their favorite search engine, types XHTML namespace, clicks the resulting link, and copies their URL bar. Because they have no templates on hand (or if they do they take longer to find than doing the above steps) and because they certainly don't remember what the damn string is, because it has 28 chars instead of 5. And if they do that they get the above string. Amusingly enough, if you repeat the exercise for SVG namespace, the results are correct. -Boris P.S. And in case you really care: wget -S -O /dev/null http://www.w3.org/1999/xhtml ... HTTP/1.1 301 Moved Permanently Location: http://www.w3.org/1999/xhtml/ Whereas http://www.w3.org/2000/svg doesn't do any redirecting. I will posit that if namespace strings were not URIs such issues would be physically impossible. -Boris
Re: Adding Web Intents to the Webapps WG deliverables
On Fri, Sep 23, 2011 at 2:20 PM, Julian Reschke julian.resc...@gmx.de wrote: Namespace names are things I copy from templates and never type from memory. Exactly, which means namespaces aren't memorable. The only reason to give up memorability is if you require the name to be both collision-free and context-free (see Zooko's Triangle). Both of those are nice (as they always are), but they're not really required for a workable namespace. Giving up memorability for no real benefit is a loss all around. In the specific case of intents, the same applies. We don't need them to be securely collision-free (collisions are slightly annoying for the user, but should be fairly rare in practice, and can be resolved by the user without a lot of trouble). They should be context-free, as they apply across the whole web. And they should be memorable, because authors have to type these and they get non-memorable things wrong. ~TJ
Re: Adding Web Intents to the Webapps WG deliverables
On 9/23/11 2:47 PM, Tab Atkins Jr. wrote: On Fri, Sep 23, 2011 at 2:20 PM, Julian Reschkejulian.resc...@gmx.de wrote: Namespace names are things I copy from templates and never type from memory. Exactly, which means namespaces aren't memorable. The only reason to give up memorability is if you require the name to be both collision-free and context-free (see Zooko's Triangle). Both of those are nice (as they always are), but they're not really required for a workable namespace. Giving up memorability for no real benefit is a loss all around. In the specific case of intents, the same applies. We don't need them to be securely collision-free (collisions are slightly annoying for the user, but should be fairly rare in practice, and can be resolved by the user without a lot of trouble). They should be context-free, as they apply across the whole web. And they should be memorable, because authors have to type these and they get non-memorable things wrong. ~TJ The search engine coalition that pushed out a set of micro-format vocabulary weighed toward using urls for itemtype in microformat: http://www.schema.org/Event Given that indexing was put forward as the case for the intent tag, how would that look in current microdata semantics? This is on webintents.org: intent action=http://webintents.org/share; type=image/* href=share.html / Would it look something like this, in microdata: meta itemscope itemtype=http://webintents.org/share; itemprop=image/* content=target.html /
Re: Adding Web Intents to the Webapps WG deliverables
On Tue, Sep 20, 2011 at 6:53 AM, Ian Hickson i...@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? Web Activities addresses this problem space without a new HTML element: https://github.com/mozilla/openwebapps/blob/master/docs/ACTIVITIES.md -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Deconstructing Intents was, Re: Adding Web Intents to the Webapps WG deliverables
On 9/20/2011 10:27 AM, Marcos Caceres wrote:
On Tuesday, September 20, 2011 at 7:17 PM, Ian Fette (イアンフェッティ) wrote:
While issuing a ton of patent exclusions for something like this would be
rather poor, I would frankly rather have that then a spec that doesn't get any
attention from a party that's clearly relevant only to have patents come up
/after/ the spec is published and implemented.
Agreed, but for that we need to go through rechartering this group to include
the new deliverable (i.e., to give everyone a fair chance to say if they are
willing to give up their IPR around this). I think your concerns are fair.
While all that gets worked out, it'd be great to have active
participation on public-webapps from Microsoft and occasional input from
the HTML5 Editor and assistant.
I'd like to see navigator.registerContentHandler integrated into Web
Intents.
window.navigator.startActivity seems like a solid addition to HTML5
NavigatorContentUtils.
There is some overlap with File API FileSaver.
I understand that Web Intents has been in development for some time: I'd
like to deconstruct and reconstruct the components to get a clear idea
of side effects.
Web Intents proposes three items: registration, invocation and schema URLs.
Invocation:
Invocation seems straightforward with startActivity. We could use
FileSaver, but
MIME does not have the added schema URL semantic that Intents adds.
Example:
var intent = new Intent(http://webintents.org/share;, text/uri-list,
http://news.bbc.co.uk;);
var saver = new FileSaver(blob, filename.ext);
FileSaver requires blob encapsulation.
Blob encapsulation is a bit of extra-work when working with array
buffers, and strings, and the like.
FileSaver Progress events are handy:
http://www.w3.org/TR/file-writer-api/#the-filesaver-interface
Schema URLs:
Web Intents proposes a new type of information, an intent keyword,
essentially.
There are a handful of common intents defined in the proposal, all of
them prefixed with http://webintents.org/;.
I'd like to see that prefix stripped. Given that Web Intents -is-
defining the standard, I do not see a good reason for the extra baggage.
I'd prefer keyword | uri as option, instead of just URI.
Thus: var intent = new Intent('share', 'text/uri-list',
'http://w3c.org'); // Much shorter.
Intents does seem to be something that can work for RPC, in addition to
current HTTP headers.
I could easily see this working across web sockets as well as it works
through intra-browser postMessage.
A Web-Intent HTTP header might prove valuable.
A URL might register itself to accept POST and Web Sockets submissions.
Consider a header of:
Web-Intent: share
A supporting server could then process that data server-side.
Registration:
Register Content/Protocol Handler: Google has limited support for these
APIs, protocol handlers, prefixed with web+ are rarely used.
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
http://code.google.com/p/chromium/issues/detail?id=11359
Web Intents-style is easy to understand, and seems to be more of a priority:
http://code.google.com/p/chromium/issues/detail?id=90458
http://code.google.com/apis/picker/docs/
Mozilla proposes registration in application manifest files:
https://github.com/mozilla/openwebapps/blob/master/docs/ACTIVITIES.md
Google has a registration technique for Chrome OS, for handling file
types by file extension.
It is limited to packaged, locally installed applications.
http://code.google.com/chrome/extensions/fileBrowserHandler.html
Permissions: Mozilla has expressed concerns about registerPermission
APIs, having used a synchronous variant for extensions.
http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
TL;DR:
FileSaver and Intent have very similar use cases -- it's quite
reasonable that a FileSaver would run an Intent session on the UA,
allowing a user to save their file to various registered targets. Look
for harmony.
Intent schema URLs seem fine, but there's no reason to have
http://webintents.org/; as a standard prefix, strip the prefix there.
Consider HTTP 1.0/Web Sockets support, as an addition to the scope.
Registration is tricky. Manifest files seem like a solid place to start.
registerHandler seems like a good addition to registerContentHandler and
registerProtocolHandler.
Re: Adding Web Intents to the Webapps WG deliverables
On Wed, 21 Sep 2011, Paul Kinlan wrote:
On Tue, 20 Sep 2011, Paul Kinlan wrote:
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).
If they're just arbitrary strings, this should be made clearer.
We will strongly encourage a URL, so we might have to say it must be a
URI to make developers think of that first. A URL gives us a lot of
advantages (more below on your sharing point).
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.
If the strings are inconvenient enough that you feel the need to
provide a constant for them, maybe that's a sign that the strings
should be changed!
Rather than 'http://webintents.org/share', why not just 'share' for
the share intent, for example?
Providing a single verb will vastly increase the chances that of
collision of competing providers saying they handle the action but
provide a completely different API.
There's no difference between two people coming up with the name foo and
two people coming up with the name http://webintents.org/foo;, unless
you're saying you're confident that people won't use the prefix the spec
uses for its verbs for their verbs.
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
A verb on its own will imply that it is a web intents verb managed by
the webintents project and all the documentation for that will live
under webintents, which means we would then need to think about
standardisation and stewardship for the entire namespace.
I don't see why. Just have a wiki page that people can list their verbs on
and then point to their documentation.
Android is a good example, the intent system is fabulous, if you look at
http://www.openintents.org/en/intentstable most developers end up
reverse name-spacing the intent and I believe when people want to
namespace their API they will either use this syntax or some other
inconsistent naming. Having a URL is nice and consistent with the web.
I think having a URL is very _in_consistent with the Web. Few technologies
use URLs for verbs, and most of them have gone nowhere fast.
URLs are Web pages. Authors find it confusing when they are used for other
things.
I'm not saying to actually use navigator.registerContentHandler and
navigator.registerProtocolHandler, but why not base something on that
API rather than reinventing the wheel?
We have two bits, one is registering the intent which we think is better
declaratively (explain more later in the email) and the second is the
invocation which we believe WI has a far simpler usage of the API and
can take advantage of postMessage.
I disagree that what you have is as simple as what you could have. In
particular, what you have is definitely not as simple (nor as powerful) as
the proposal I put at the end of my e-mail, for instance.
Specifically we want to get away from having to wait for the remote app
to tell us it is ready before we pass it the data - which is what
happens if we currently use window.open with a scheme register with RPH
RCH etc.
The proposal I put forward does not have this problem.
var intent = new Intent(http://webintents.org/share;,
image/png, getData());
window.navigator.startActivity(intent, function(data) {
doSomethingAwesome(data);
});
var port = navigator.handleIntent(share, image/png);
port.postMessage(getData());
port.onmessage = function (event) { doSomethingAwesome(event.data) };
Sure, but what if the full interface is already open? Maybe Google+ is
a better example: you could envisage the Share dialog appearing on
the open Google+ page rather than opening an entirely new page just to
share a post.
I think this is an important case to support.
We thought about this, we didn't want to overwrite the current task that
the user was performing and we didn't want to have a user launch two
intents and overwrite what they we working on the previous invocation.
By not supporting the use case at all I think you are overcompensating. :-)
If an application wants to support this case, why not let it? With a model
such as the one I propose, it's essentially free.
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
Re: Adding Web Intents to the Webapps WG deliverables
Hey Ian, comments in-line. On Thu, Sep 22, 2011 at 2:36 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 21 Sep 2011, Paul Kinlan wrote: On Tue, 20 Sep 2011, Paul Kinlan wrote: 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). If they're just arbitrary strings, this should be made clearer. We will strongly encourage a URL, so we might have to say it must be a URI to make developers think of that first. A URL gives us a lot of advantages (more below on your sharing point). 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. If the strings are inconvenient enough that you feel the need to provide a constant for them, maybe that's a sign that the strings should be changed! Rather than 'http://webintents.org/share', why not just 'share' for the share intent, for example? Providing a single verb will vastly increase the chances that of collision of competing providers saying they handle the action but provide a completely different API. There's no difference between two people coming up with the name foo and two people coming up with the name http://webintents.org/foo;, unless you're saying you're confident that people won't use the prefix the spec uses for its verbs for their verbs. 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. A verb on its own will imply that it is a web intents verb managed by the webintents project and all the documentation for that will live under webintents, which means we would then need to think about standardisation and stewardship for the entire namespace. I don't see why. Just have a wiki page that people can list their verbs on and then point to their documentation. We plan to employ a model such as this. openintents.org currently lists third-party intents for the Android system, though we could use that site to enumerate Web Intents. Android is a good example, the intent system is fabulous, if you look at http://www.openintents.org/en/intentstable most developers end up reverse name-spacing the intent and I believe when people want to namespace their API they will either use this syntax or some other inconsistent naming. Having a URL is nice and consistent with the web. I think having a URL is very _in_consistent with the Web. Few technologies use URLs for verbs, and most of them have gone nowhere fast. URLs are Web pages. Authors find it confusing when they are used for other things. I'm not saying to actually use navigator.registerContentHandler and navigator.registerProtocolHandler, but why not base something on that API rather than reinventing the wheel? We have two bits, one is registering the intent which we think is better declaratively (explain more later in the email) and the second is the invocation which we believe WI has a far simpler usage of the API and can take advantage of postMessage. I disagree that what you have is as simple as what you could have. In particular, what you have is definitely not as simple (nor as powerful) as the proposal I put at the end of my e-mail, for instance. Specifically
Re: Adding Web Intents to the Webapps WG deliverables
On Thu, Sep 22, 2011 at 3:28 PM, James Hawkins jhawk...@google.com wrote: 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. URLs are really, really not a good namespacing mechanism, because URLs are not names in practice. Names are compared with string-equality, generally. URLs are compared as URLs, which is a lot crazier. Is http://dev.twitter.com/tweet; the same action as http://dev.twitter.com/tweet/;? What about https://dev.twitter.com/tweet; or //dev.twitter.com/tweet or /tweet (assume this last one is on a page within dev.twitter.com)? There's a decent chance that all of these are considered the same url by devs, and devs will probably attempt to use them. I haven't even mentioned yet the presence/absence of www in urls. Will this mistake be caught when it doesn't work? Some of the time, yeah. A lot of devs won't go through and test every intent they add. Even if they do, they may just test with the same incorrect URL they registered with, and then be bewildered when they're not getting the traffic they think they should be (and it's even worse for users, who thought they let the page register for tweeting, but it only works some of the time, when other devs accidentally use the same incorrect url). ~TJ
Re: Adding Web Intents to the Webapps WG deliverables
On 9/22/2011 2:36 PM, Ian Hickson wrote: On Wed, 21 Sep 2011, Paul Kinlan wrote: On Tue, 20 Sep 2011, Paul Kinlan wrote: 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). If they're just arbitrary strings, this should be made clearer. We will strongly encourage a URL, so we might have to say it must be a URI to make developers think of that first. A URL gives us a lot of advantages (more below on your sharing point). 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. If the strings are inconvenient enough that you feel the need to provide a constant for them, maybe that's a sign that the strings should be changed! Rather than 'http://webintents.org/share', why not just 'share' for the share intent, for example? Providing a single verb will vastly increase the chances that of collision of competing providers saying they handle the action but provide a completely different API. There's no difference between two people coming up with the name foo and two people coming up with the name http://webintents.org/foo;, unless you're saying you're confident that people won't use the prefix the spec uses for its verbs for their verbs. That appears to me what he's saying. I think experimenting developers are just as likely to [ab-]use the default namespace as http://webintents.org, if they're not following guidelines. I'd really like to see that default namespace dropped. It's just not necessary. It feels more like advertising than a resource. A verb on its own will imply that it is a web intents verb managed by the webintents project and all the documentation for that will live under webintents, which means we would then need to think about standardisation and stewardship for the entire namespace. I don't see why. Just have a wiki page that people can list their verbs on and then point to their documentation. I agree here. The standard is sufficient for stewardship. In the specification, you're defining the verb as DOMString, no restrictions. If that's the case, there's no need for formal stewardship beyond the standard. And there's no need for webintents.org to be mentioned in common use of the share verb. Android is a good example, the intent system is fabulous, if you look at http://www.openintents.org/en/intentstable most developers end up reverse name-spacing the intent and I believe when people want to namespace their API they will either use this syntax or some other inconsistent naming. Having a URL is nice and consistent with the web. I think having a URL is very _in_consistent with the Web. Few technologies use URLs for verbs, and most of them have gone nowhere fast. URLs are Web pages. Authors find it confusing when they are used for other things. It's been pretty common in XML-land to use URLs. Developers are familiar with reverse name-spacing, URL semantics are a bit heavy: com.facebook.like vs. https://www.facebook.com/like If that end-point isn't used for any particular validation, it's overly verbose. The protocol adds nothing. I'd like to see schema matches reserved for future use, putting them in sync with registerProtocolHandler. As verbs are not validated against anything in particular, it'd be nice to have https://* as a means for additional validation / verb registration. I'm fine with the list of reserved strings, but I don't want http://webintents.org/ as a prefix. It's a waste for my fingers to type. I'm not saying to actually use navigator.registerContentHandler and navigator.registerProtocolHandler, but why not base something on that API rather than reinventing the wheel? We have two bits, one is registering the intent which we think is better declaratively (explain more later in the email) and the second is the invocation which we believe WI has a far simpler usage of the API and can take advantage of postMessage. I disagree that what you have is as simple as what you could have. In particular, what you have is definitely not as simple (nor as powerful) as the proposal I put at the end of my e-mail, for instance. They're both simple proposals. I would like to see a common means for expressing web intents in HTML. I don't think the current intent tag is sufficient. Vendors are heading to link rel; such as, http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html Can it be squeezed into link semantics, instead of introducing a new tag? Specifically we want to get away from having to wait for the remote app to tell us it is ready before we pass it the data - which is what happens if we currently use window.open with
Re: Adding Web Intents to the Webapps WG deliverables
On Thu, Sep 22, 2011 at 5:22 PM, Charles Pritchard ch...@jumis.com wrote: I don't see why. Just have a wiki page that people can list their verbs on and then point to their documentation. I agree here. The standard is sufficient for stewardship. Why won't I create a bot that fills with wiki with a dictionary's worth of verbs point to my important intent: making money on advertising? My own personal single-point of control. Oh, you think your bot is faster than mine? We'll see about that! Oh, the wiki domain owners stepped in? Set up a committee to approve changes? Censorship! Politics! Slowness! And so on. jjb
Re: Adding Web Intents to the Webapps WG deliverables
On 09/20/2011 11:27 PM, Bjoern Hoehrmann wrote: with the Web Applications Working Group, which after six years has a XMLHttpRequest test suite consisting of nothing but There is a good chance a test suite for XMLHttpRequest will be placed around here and no XMLHttpRequest specification to show. http://www.w3.org/TR/XMLHttpRequest/ http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/
Re: Adding Web Intents to the Webapps WG deliverables
Ian Hickson wrote: Why not just improve both navigator.registerContentHandler and navigator.registerProtocolHandler? http://groups.google.com/group/web-intents/browse_thread/thread/3dff7c2cdf5815b8 I tend to agree with rolling this in to RCH and RPH and seeing if we could refine the processing algorithms therein to satisfy the security issues highlighted in that thread (i.e. ensuring the cross document messaging channel setup from a window.open with a registered protocol handler is origin bound).
Re: Adding Web Intents to the Webapps WG deliverables
With all due respect, I think that if we have to re-charter or create a new working group each time a new API comes up we are all doomed. The overhead of creating and monitoring so many WGs is not appealing to many of us. On Tue, Sep 20, 2011 at 6:55 AM, Robin Berjon ro...@berjon.com wrote: Hi James, thanks for bringing this forward, it is indeed a very interesting approach. On Sep 19, 2011, at 22:27 , James Hawkins wrote: I've read through the Webapps charter, and I believe Web Intents fits the goals and scope of the WG. It does fit the goal and scope, but then most web client technology does ;) Where you may run into issues is that it does not fit in the deliverables list. Since that is what members makes their IP commitment on, a new deliverable of non-negligible content might require rechartering. Last time we did that, it wasn't very pleasant. Thankfully, there is already a group that was chartered with Intents (or, in the poetic phrasing of charters, with an API that allows web applications to register themselves as handlers/providers based on data string identifiers and an API that enables other web applications to discover these handlers/providers and gain permission to interact with them — but Intents is what that means): the Device APIs group, http://www.w3.org/2011/07/DeviceAPICharter. It'd save a lot on the bureaucracy and allow us all to just go straight to work. We'd certainly be happy to accept your draft input. The new DAP is meant to be completely flexible in how it is organised. Notably, if you prefer to conduct work on this spec without necessarily getting all the email from the rest of the group we can setup a dedicated Task Force with its own mailing list and chair (if there's a volunteer, otherwise I'll do it). TFs can decide whether they want to have telcons or not. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Adding Web Intents to the Webapps WG deliverables
Hi Ian, On Sep 20, 2011, at 16:04 , Ian Fette (イアンフェッティ) wrote: With all due respect, I think that if we have to re-charter or create a new working group each time a new API comes up we are all doomed. The overhead of creating and monitoring so many WGs is not appealing to many of us. That's a recurring theme, with the following constraints: • people with IP don't want wildcard groups because the IP risks for them are hard to evaluate; • people who want to get work done don't want to have to jump through the bureaucratic hoops of creating new groups; • people who are focused on a single topic complain about monster groups that cover too many topics. So there probably isn't an option that will make everyone happy, though improvements are being discussed. Thankfully those problems don't apply here. There is an existing group so there's no need for bureaucratic hoops — those have been handled and everything is primed to go. The overhead involved in monitoring it involves clicking the form to join it and filtering the related list somewhere convenient — which can be the same mailbox as an existing one if there's too much overhead involved in reading from two mailboxes. So can we quit the process discussion and just get to work? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Adding Web Intents to the Webapps WG deliverables
I don't get it. The overhead of getting all the other browsers to join the WG you mention is just as high, especially when there's no indication that a number of browsers intend to join that group. I don't think it's a random process question, I think it's rather fundamental issue. If we agree that the right way forward is to create a new WG for each API and we have to get people to join each WG to get any IP considerations, it would be much more effective just to do things in WHATWG and mail out a please sign this and return letter. It would probably get the same number of responses and be a hell of a lot lower overhead, while effectively offering as much (or rather, as little) benefit as we get from being forced to start a new group for each API. -Ian On Tue, Sep 20, 2011 at 7:21 AM, Robin Berjon ro...@berjon.com wrote: Hi Ian, On Sep 20, 2011, at 16:04 , Ian Fette (イアンフェッティ) wrote: With all due respect, I think that if we have to re-charter or create a new working group each time a new API comes up we are all doomed. The overhead of creating and monitoring so many WGs is not appealing to many of us. That's a recurring theme, with the following constraints: • people with IP don't want wildcard groups because the IP risks for them are hard to evaluate; • people who want to get work done don't want to have to jump through the bureaucratic hoops of creating new groups; • people who are focused on a single topic complain about monster groups that cover too many topics. So there probably isn't an option that will make everyone happy, though improvements are being discussed. Thankfully those problems don't apply here. There is an existing group so there's no need for bureaucratic hoops — those have been handled and everything is primed to go. The overhead involved in monitoring it involves clicking the form to join it and filtering the related list somewhere convenient — which can be the same mailbox as an existing one if there's too much overhead involved in reading from two mailboxes. So can we quit the process discussion and just get to work? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Adding Web Intents to the Webapps WG deliverables
Hi Ian! On Sep 20, 2011, at 16:26 , Ian Fette (イアンフェッティ) wrote: I don't get it. The overhead of getting all the other browsers to join the WG you mention is just as high Can you please detail what overhead that involves? There are only two cases here: • You have IP concerns relevant to Web Intents. In that case you need IP portfolio review. That overhead is the same for joining and for rechartering an existing group (it's just politically higher in the rechartering case). • You don't have IP concerns relevant to Web Intents. In that case you just join the group — zero overhead. It's a simple solution that just involves clicking through a form. If you have a political mexican standoff of vendors not joining while the others aren't, it can hardly be blamed on the process, DAP, WebApps, W3C, or whatever else. I'm sure that it can be sorted out, though. Intents were initially added to DAP's charter in good part because Google asked us to. It's a little annoying to be blamed for doing exactly what you were asked to do. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Adding Web Intents to the Webapps WG deliverables
On 9/20/2011 7:55 AM, Robin Berjon wrote: Hi Ian! On Sep 20, 2011, at 16:26 , Ian Fette (イアンフェッティ) wrote: I don't get it. The overhead of getting all the other browsers to join the WG you mention is just as high Can you please detail what overhead that involves? There are only two cases here: • You have IP concerns relevant to Web Intents. In that case you need IP portfolio review. That overhead is the same for joining and for rechartering an existing group (it's just politically higher in the rechartering case). • You don't have IP concerns relevant to Web Intents. In that case you just join the group — zero overhead. It's a simple solution that just involves clicking through a form. If you have a political mexican standoff of vendors not joining while the others aren't, it can hardly be blamed on the process, DAP, WebApps, W3C, or whatever else. I'm sure that it can be sorted out, though. Intents were initially added to DAP's charter in good part because Google asked us to. It's a little annoying to be blamed for doing exactly what you were asked to do. There is certainly some overlap between DAP and WebApps. Is that the issue here, Robin? I don't have much of a solution for it: I've been looking at DAP as an incubator with a broad scope and a good history of experimentation. -Charles
Re: Adding Web Intents to the Webapps WG deliverables
Hi Charles, On Sep 20, 2011, at 17:15 , Charles Pritchard wrote: There is certainly some overlap between DAP and WebApps. Is that the issue here, Robin? If you ask me, there isn't any issue at all :) James suggested that WebApps take over Intents. Since it isn't in WebApps's deliverables, this could require some process mongering which I think we can all agree is an annoying waste of time. As it happens however, DAP already has Intents in its charter, so getting to work right now rather than walking the bureaucratic path is a simple matter of doing the work there. I'm advocating a JFDI approach over politicking and bureaucracy. That's all there is to it. Put another way, I too would like there to be just one huge Web APIs group that would handle all of WebApps, DAP, Web Events, Geolocation, and a bunch of other groups. But we don't have that and there's opposition to the notion. So instead of lamenting that issue, let's just use the tools we have that in this case happen to be both in place and perfectly serviceable. I don't have much of a solution for it: I've been looking at DAP as an incubator with a broad scope and a good history of experimentation. Yeah, DAP has been very fluid in its approaches and is certainly a group in which this proposed spec can just hit the ground running. That's why I'm offering this solution over jumping through process hoops, which I really don't see the entertainment value in. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Adding Web Intents to the Webapps WG deliverables
On 9/20/2011 8:57 AM, Robin Berjon wrote: Hi Charles, On Sep 20, 2011, at 17:15 , Charles Pritchard wrote: There is certainly some overlap between DAP and WebApps. Is that the issue here, Robin? If you ask me, there isn't any issue at all :) James suggested that WebApps take over Intents. Since it isn't in WebApps's deliverables, this could require some process mongering which I think we can all agree is an annoying waste of time. As it happens however, DAP already has Intents in its charter, so getting to work right now rather than walking the bureaucratic path is a simple matter of doing the work there. I'm advocating a JFDI approach over politicking and bureaucracy. That's all there is to it. Put another way, I too would like there to be just one huge Web APIs group that would handle all of WebApps, DAP, Web Events, Geolocation, and a bunch of other groups. But we don't have that and there's opposition to the notion. So instead of lamenting that issue, let's just use the tools we have that in this case happen to be both in place and perfectly serviceable. I don't have much of a solution for it: I've been looking at DAP as an incubator with a broad scope and a good history of experimentation. Yeah, DAP has been very fluid in its approaches and is certainly a group in which this proposed spec can just hit the ground running. That's why I'm offering this solution over jumping through process hoops, which I really don't see the entertainment value in. I've no objection to delivering it in DAP while discussing it on public-webapps. -Charles
Re: Adding Web Intents to the Webapps WG deliverables
On Tue, Sep 20, 2011 at 8:57 AM, Robin Berjon ro...@berjon.com wrote: Hi Charles, On Sep 20, 2011, at 17:15 , Charles Pritchard wrote: There is certainly some overlap between DAP and WebApps. Is that the issue here, Robin? If you ask me, there isn't any issue at all :) James suggested that WebApps take over Intents. Since it isn't in WebApps's deliverables, this could require some process mongering which I think we can all agree is an annoying waste of time. As it happens however, DAP already has Intents in its charter, so getting to work right now rather than walking the bureaucratic path is a simple matter of doing the work there. There's process mongering to get relevant parties to join DAP. This is not free. If you can guarantee me that the other browsers will join DAP then let's talk (namely MSFT who just announced a similar spec for Metro, and it would be very important to get their input here.) I'm advocating a JFDI approach over politicking and bureaucracy. That's all there is to it. Put another way, I too would like there to be just one huge Web APIs group that would handle all of WebApps, DAP, Web Events, Geolocation, and a bunch of other groups. But we don't have that and there's opposition to the notion. So instead of lamenting that issue, let's just use the tools we have that in this case happen to be both in place and perfectly serviceable. I don't have much of a solution for it: I've been looking at DAP as an incubator with a broad scope and a good history of experimentation. Yeah, DAP has been very fluid in its approaches and is certainly a group in which this proposed spec can just hit the ground running. That's why I'm offering this solution over jumping through process hoops, which I really don't see the entertainment value in. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Adding Web Intents to the Webapps WG deliverables
On Tuesday, September 20, 2011 at 7:09 PM, Ian Fette (イアンフェッティ) wrote: On Tue, Sep 20, 2011 at 8:57 AM, Robin Berjon ro...@berjon.com (mailto:ro...@berjon.com) wrote: Hi Charles, On Sep 20, 2011, at 17:15 , Charles Pritchard wrote: There is certainly some overlap between DAP and WebApps. Is that the issue here, Robin? If you ask me, there isn't any issue at all :) James suggested that WebApps take over Intents. Since it isn't in WebApps's deliverables, this could require some process mongering which I think we can all agree is an annoying waste of time. As it happens however, DAP already has Intents in its charter, so getting to work right now rather than walking the bureaucratic path is a simple matter of doing the work there. There's process mongering to get relevant parties to join DAP. This is not free. If you can guarantee me that the other browsers will join DAP then let's talk (namely MSFT who just announced a similar spec for Metro, and it would be very important to get their input here.) That presupposes that Microsoft would have anything to say even in this WG. Obviously, I can't speak for Microsoft (and I won't), but just because someone is part of the WG doesn't mean that they will say anything … or worst, they will just exclude patents willy-nilly like Apple did with Widgets. That's a much crappier situation, so careful for what you wish for :)
Re: Adding Web Intents to the Webapps WG deliverables
On Tue, Sep 20, 2011 at 10:15 AM, Marcos Caceres w...@marcosc.com wrote: On Tuesday, September 20, 2011 at 7:09 PM, Ian Fette (イアンフェッティ) wrote: On Tue, Sep 20, 2011 at 8:57 AM, Robin Berjon ro...@berjon.com (mailto: ro...@berjon.com) wrote: Hi Charles, On Sep 20, 2011, at 17:15 , Charles Pritchard wrote: There is certainly some overlap between DAP and WebApps. Is that the issue here, Robin? If you ask me, there isn't any issue at all :) James suggested that WebApps take over Intents. Since it isn't in WebApps's deliverables, this could require some process mongering which I think we can all agree is an annoying waste of time. As it happens however, DAP already has Intents in its charter, so getting to work right now rather than walking the bureaucratic path is a simple matter of doing the work there. There's process mongering to get relevant parties to join DAP. This is not free. If you can guarantee me that the other browsers will join DAP then let's talk (namely MSFT who just announced a similar spec for Metro, and it would be very important to get their input here.) That presupposes that Microsoft would have anything to say even in this WG. Obviously, I can't speak for Microsoft (and I won't), but just because someone is part of the WG doesn't mean that they will say anything … or worst, they will just exclude patents willy-nilly like Apple did with Widgets. That's a much crappier situation, so careful for what you wish for :) While issuing a ton of patent exclusions for something like this would be rather poor, I would frankly rather have that then a spec that doesn't get any attention from a party that's clearly relevant only to have patents come up /after/ the spec is published and implemented.
Re: Adding Web Intents to the Webapps WG deliverables
On Tuesday, September 20, 2011 at 7:17 PM, Ian Fette (イアンフェッティ) wrote: While issuing a ton of patent exclusions for something like this would be rather poor, I would frankly rather have that then a spec that doesn't get any attention from a party that's clearly relevant only to have patents come up /after/ the spec is published and implemented. Agreed, but for that we need to go through rechartering this group to include the new deliverable (i.e., to give everyone a fair chance to say if they are willing to give up their IPR around this). I think your concerns are fair.
Re: Adding Web Intents to the Webapps WG deliverables
On Tue, Sep 20, 2011 at 10:27 AM, Marcos Caceres w...@marcosc.com wrote: On Tuesday, September 20, 2011 at 7:17 PM, Ian Fette (イアンフェッティ) wrote: While issuing a ton of patent exclusions for something like this would be rather poor, I would frankly rather have that then a spec that doesn't get any attention from a party that's clearly relevant only to have patents come up /after/ the spec is published and implemented. Agreed, but for that we need to go through rechartering this group to include the new deliverable (i.e., to give everyone a fair chance to say if they are willing to give up their IPR around this). I think your concerns are fair. Why do we need to recharter? I don't get the point of having a WG that has to recharter every single time that we develop a new API. Maybe we should just stop developing new APIs? The W3C patent policy lets people exclude things if they so wish, and I don't deny anyone that right. But if we go to a world where we say Let's create a new WG for each API then we get no benefit out of the W3C whatsoever. We aren't guaranteed wide review of the APIs, most WGs probably won't have all the relevant people participating, and so then we will still have all the worries about relevant patents not being disclosed or licensed, and frankly at that point W3C offers nothing that WHATWG does not except for a ton of process overhead. If we have to create a new WG for each new API, I propose we just do it all in WHATWG.
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
Re: Adding Web Intents to the Webapps WG deliverables
Hi Robin, On Tue, Sep 20, 2011 at 7:55 AM, Robin Berjon ro...@berjon.com wrote: Hi Ian! On Sep 20, 2011, at 16:26 , Ian Fette (イアンフェッティ) wrote: I don't get it. The overhead of getting all the other browsers to join the WG you mention is just as high Can you please detail what overhead that involves? There are only two cases here: * You have IP concerns relevant to Web Intents. In that case you need IP portfolio review. That overhead is the same for joining and for rechartering an existing group (it's just politically higher in the rechartering case). * You don't have IP concerns relevant to Web Intents. In that case you just join the group ― zero overhead. It's a simple solution that just involves clicking through a form. If you have a political mexican standoff of vendors not joining while the others aren't, it can hardly be blamed on the process, DAP, WebApps, W3C, or whatever else. I'm sure that it can be sorted out, though. Intents were initially added to DAP's charter in good part because Google asked us to. It's a little annoying to be blamed for doing exactly what you were asked to do. I'm the TL of the Intents team at Google, but this is a large company and I've only been involved with the larger Open Web Platform team for ~6 months. I'm not familiar with the details surrounding Google asking DAP to add Intents to the charter. Can you fill me in on the details? To clarify on my end, the current draft of the Web Intents API is entering a cluttered namespace; there are several proposals with similar names/ideas that are not directly tied to this API: * Web Introducer/Web-send (Tyler Close, published early 2010) * Web Intents (Paul Kinlan, published in Nov 2010) If my hunch is right, you're referring to Tyler's Introducer proposal; note that while Tyler does work at Google, his work on Introducer was not tied to the Chrome team. The Web Intents proposal of this thread has the backing of the Chrome team which has agreed that Intents is the way to move forward in this problem space. Thanks, James
Re: Adding Web Intents to the Webapps WG deliverables
HI Ian, On Sep 20, 2011, at 19:38 , Ian Fette (イアンフェッティ) wrote: Why do we need to recharter? I don't get the point of having a WG that has to recharter every single time that we develop a new API. I can't begin to tell you how sympathetic I am to this feeling, and the frustration that goes with. As a freelance web hacker I have no IP to care for, and I very much wish that all companies with IP portfolios had the same attitude that you have. But that's hardly under my control and I'm merely pointing out that pushing this through WebApps risks bureaucratic overhead whereas there is an option that involves no bureaucracy. Note that if your primary concern is Microsoft providing feedback, if they so wish they always can. They've provided extensive feedback to DAP in the past, e.g. http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html#capture_api_extensions But if we go to a world where we say Let's create a new WG for each API then we get no benefit out of the W3C whatsoever. Hear, hear. Thankfully in this case it's a WG that's already created, and has ~15 deliverables. Still smaller than WebApps, but better than 15 WGs! Note that a complicating factor is that the feedback we got from others (e.g. Mozilla) was the opposite: they'd rather have seen DAP be several smaller WGs. It's hard to please everyone, which is precisely why I'm so keen to avoid pushing this into process-space, getting to work where it's process-easiest, and ensuring reviews in every way we know. If people want to review they will no matter which group it's in; if they don't it won't happen even if they are in the group. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Adding Web Intents to the Webapps WG deliverables
* Ian Fette wrote: I don't get it. The overhead of getting all the other browsers to join the WG you mention is just as high, especially when there's no indication that a number of browsers intend to join that group. I don't think it's a random process question, I think it's rather fundamental issue. If we agree that the right way forward is to create a new WG for each API [...] The idea is to record in charters what working groups are expected to deliver to allow proper review, planning, allocation of resources, and so on. A coarse characterization will make those things difficult, and a very narrow characterization will make taking up new work difficult. Surprising new requirements come with more overhead than things that have been anticipated well in advance; but that's not one WG per API. I note that these processes are not designed to minimize hurdles for a handful of browser vendors, but for broad consensus and high quality deliverables that arrive reasonably predictably. That requires parties to synchronize. Removing synchronization pressure leads to what we have with the Web Applications Working Group, which after six years has a XMLHttpRequest test suite consisting of nothing but There is a good chance a test suite for XMLHttpRequest will be placed around here and no XMLHttpRequest specification to show. There are drafts and submissions, but it would seem people regard this state of affairs as good enough and so there is little pressure to pull things together and push out a proper release. And I note the same goes for earlier stages aswell, the process being largely unpredictable as it is driven by when one or more of a handful people feel like it, it becomes very difficult for out-of-the-loop parties to meaningfully en- gage in the process. If you mostly want to sanity-check reasonably com- plete documents, which should you review? The first Last Call? Second? Third? Fourth? Fith Last Call? Third Candidate Recommendation? When can we expect a reasonable test suite to verify everything is interoperable enough to remove vendor prefixes? Seven years? Oh there is a couple of Webkit specific tests somewhere in the source tree, we think this is good enough so we just throw it out there with no proper test suite? It's not a matter of this has more overhead than that, but a matter of what we, all of us, want to get out of the standards process, and what of that can reasonably be achieved within constraints we have. It may be for instance that we are moving too fast, and should not work at this point on Web Intents and instead use what limited resources there are to finish some of the pending work first. It may also be we don't care about this silly business with Recommendations and Tests so this can easily be added. Or we might find that we need to invest more resources so we can do more things in parallel. Or something else. But without an understanding what the process should produce and support, which we quite clearly lack, at least collectively, there is no point in arguing that process A is better than process B. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Adding Web Intents to the Webapps WG deliverables
On Tue, 20 Sep 2011, Rich Tibbett wrote: Ian Hickson wrote: Why not just improve both navigator.registerContentHandler and navigator.registerProtocolHandler? http://groups.google.com/group/web-intents/browse_thread/thread/3dff7c2cdf5815b8 I tend to agree with rolling this in to RCH and RPH and seeing if we could refine the processing algorithms therein to satisfy the security issues highlighted in that thread (i.e. ensuring the cross document messaging channel setup from a window.open with a registered protocol handler is origin bound). I'm not sure it necessarily makes sense to use registerProtocolHandler() itself, but something based on it seems like it would work, rather than reinventing the wheel entirely. On Tue, 20 Sep 2011, Paul Kinlan wrote: 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). If they're just arbitrary strings, this should be made clearer. 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. If the strings are inconvenient enough that you feel the need to provide a constant for them, maybe that's a sign that the strings should be changed! Rather than 'http://webintents.org/share', why not just 'share' for the share intent, for example? 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. This needs to be defined much more precisely. e.g. what happens to MIME parameters? Does */* match foo/*? What syntax checking is done on the inputs here? 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. I'm not saying to actually use navigator.registerContentHandler and navigator.registerProtocolHandler, but why not base something on that API rather than reinventing the wheel? We want one consistent way of delivering data to applications Soemthing based on navigator.register*Handler() would give you that. Inventing something new wouldn't, since then you'd have two mechanisms (the register*Handler() methods, and Web Intents). we want it to be a client-side delivery mechanism If it's going to be entirely client-side, I would recommend using MessagePorts, so that the communication isn't just one-post, one-response. For example, consider an intent where the provider needs to take the submitted data, encrypt it, then hand it back to the original site for a signature, then needs to take the result and send it somewhere. With a mechanism that just consists of post/response, there's no good way to get the data back (you'd have to do it on the server end). If we provide ports to communicate back and forth, you wouldn't have a problem. and we want applications to be able to tell the action it supports and the data types it can handle. That doesn't seem hard to do if we just work on an extension to register*Handler(). No need for a completely different API. 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. Sure, but what if the full interface is already open? Maybe Google+ is a better example: you could envisage the Share dialog appearing on the open Google+ page rather than opening an entirely new page just to share a post. I think this is an important case to support. 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. Could you elaborate on this need? What use case does it address? Adding new elements (especially to head) is a high-cost affair and should be avoided unless there are really good reasons for it. Flexibility for the UA; the UA gets a much richer understanding of the capabilities of
Re: Adding Web Intents to the Webapps WG deliverables
Some comments inline - I hope they don't get lost. On Tue, Sep 20, 2011 at 11:34 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 20 Sep 2011, Rich Tibbett wrote: Ian Hickson wrote: Why not just improve both navigator.registerContentHandler and navigator.registerProtocolHandler? http://groups.google.com/group/web-intents/browse_thread/thread/3dff7c2cdf5815b8 I tend to agree with rolling this in to RCH and RPH and seeing if we could refine the processing algorithms therein to satisfy the security issues highlighted in that thread (i.e. ensuring the cross document messaging channel setup from a window.open with a registered protocol handler is origin bound). I'm not sure it necessarily makes sense to use registerProtocolHandler() itself, but something based on it seems like it would work, rather than reinventing the wheel entirely. On Tue, 20 Sep 2011, Paul Kinlan wrote: 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). If they're just arbitrary strings, this should be made clearer. We will strongly encourage a URL, so we might have to say it must be a URI to make developers think of that first. A URL gives us a lot of advantages (more below on your sharing point). 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. If the strings are inconvenient enough that you feel the need to provide a constant for them, maybe that's a sign that the strings should be changed! Rather than 'http://webintents.org/share', why not just 'share' for the share intent, for example? Providing a single verb will vastly increase the chances that of collision of competing providers saying they handle the action but provide a completely different API. A verb on its own will imply that it is a web intents verb managed by the webintents project and all the documentation for that will live under webintents, which means we would then need to think about standardisation and stewardship for the entire namespace. We don't want to become the IANA and have an amazingly formal process ( http://tools.ietf.org/html/rfc4395) of registration. Rather this can be lightweight and delegated out to who owns the domain and they can manage their specs, supported intents and importantly developer support. If we use URL as the first filter, we have the documentation endpoint and the namespaces for developers to experiment build upon with little fear of impacting others. We have had developers want to hook up transcription services and OCR services, we worry that without namespacing and the presence of a strictly formal process people stop building their own API's and endpoints. Android is a good example, the intent system is fabulous, if you look at http://www.openintents.org/en/intentstable most developers end up reverse name-spacing the intent and I believe when people want to namespace their API they will either use this syntax or some other inconsistent naming. Having a URL is nice and consistent with the web. 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. This needs to be defined much more precisely. e.g. what happens to MIME parameters? Does */* match foo/*? What syntax checking is done on the inputs here? * matches foo/* - we should clear the documentation up. We didn't think */png as an example would make sense so */* is contracted to *. 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. I'm not saying to actually use navigator.registerContentHandler and navigator.registerProtocolHandler, but why not base something on that API rather than reinventing the wheel? We have two bits, one is registering the intent which we think is better declaratively (explain more later in the email) and the second is the invocation which we believe WI has a far simpler usage of the API and can take advantage of postMessage. We want one consistent way of delivering data to applications Soemthing based on navigator.register*Handler() would give you that. Inventing something new wouldn't, since then you'd have two mechanisms (the register*Handler() methods, and Web Intents). Specifically we want to get away from having to wait for the remote app to tell us it is ready before we pass it the data - which is what happens if we
Adding Web Intents to the Webapps WG deliverables
I'm forwarding this on behalf of a colleague whose message seems caught up in a moderation queue. Apologies if it results in a duplicate message for anyone. -- Forwarded message -- From: James Hawkins jhawk...@google.com Date: Mon, Sep 19, 2011 at 1:27 PM Subject: Adding Web Intents to the Webapps WG deliverables To: public-webapps@w3.org I am the tech lead for the team designing and implementing Web Intents [1] for Chrome at Google. Web Intents is a web platform feature modeled after the similarly named feature in Android OS. Web Intents enables client sites to request high-level functionality, e.g. share, edit, pick, upload, auth, from an unknown (to the client) provider. The UA enumerates the list of registered providers that the user has already accepted as Intent handlers, allowing the user to pick which provider she wants to use for the particular action. This feature is not a panacea, nor do we envision it as a 'meta API'; however, the use cases we've focused on will make web apps much more connected and useful for users. Take the NASCAR problem: with Web Intents, publishers can get rid of maintaining an ever-growing list of 'share' providers, replacing them with one share button that kicks off the 'share' action. The user only sees the sites that she actively uses. Note: we're actively working with Mozilla on the API, and the draft I have prepared has been agreed upon by both vendors. I've read through the Webapps charter, and I believe Web Intents fits the goals and scope of the WG. Goals * Promote universal access to Web applications across a wide range of devices. - Web Intents can be implemented in browsers on all devices, and more importantly, the feature is a perfect conduit for hooking into platform functionality (Android Intents, iOS API, a scalable registerProtocolHandler). * Promote creation of tutorials and other educational material. - Check out http://examples.webintents.org where we have example clients/providers of Web Intents using a JS shim that works across all current browsers. - The action string in the API is suggested to be a URL pointing to documentation for the action, e.g., http://webintents.org/share is both the string for the 'share' action and the URL of the documentation for said action. Scope * Markup vocabularies for describing and controlling client-side application behavior. - Web Intents provides an intent tag that allows provider sites to declare which intent actions they handle. * Programming interfaces for client-side development: platform interaction. - As stated above, this feature can easily be extended to hook into the platform to, say, allow the UA to notify providers of platform events or data sources, e.g., plugging in a camera. The developers of this API, from both Mozilla and Google, believe Webapps is the right home for Web Intents. I'd like to open discussion on the topic and get your feedback. Ultimately we'd like to take the next steps towards getting Web Intents officially out in the open, actively developed by the larger Webapps community. Thanks, James Hawkins [1] http://dev.chromium.org/developers/design-documents/webintentsapi
Re: Adding Web Intents to the Webapps WG deliverables
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. `._.-(,_..'--(,_..'`-.;.'
Re: Adding Web Intents to the Webapps WG deliverables
Should Paul Kinlan be Cc'd on this? His concept work is helpful. On Sep 19, 2011, at 8:53 PM, Ian Hickson i...@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. `._.-(,_..'--(,_..'`-.;.'
Re: Adding Web Intents to the Webapps WG deliverables
+Paul Kinlan, Greg Billock - from Google team. +Mike Hanson, Ben Adida - from Mozilla team. On Mon, Sep 19, 2011 at 9:25 PM, Charles Pritchard ch...@jumis.com wrote: Should Paul Kinlan be Cc'd on this? His concept work is helpful. On Sep 19, 2011, at 8:53 PM, Ian Hickson i...@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. `._.-(,_..'--(,_..'`-.;.'
Adding Web Intents to the Webapps WG deliverables
I am the tech lead for the team designing and implementing Web Intents [1] for Chrome at Google. Web Intents is a web platform feature modeled after the similarly named feature in Android OS. Web Intents enables client sites to request high-level functionality, e.g. share, edit, pick, upload, auth, from an unknown (to the client) provider. The UA enumerates the list of registered providers that the user has already accepted as Intent handlers, allowing the user to pick which provider she wants to use for the particular action. This feature is not a panacea, nor do we envision it as a 'meta API'; however, the use cases we've focused on will make web apps much more connected and useful for users. Take the NASCAR problem: with Web Intents, publishers can get rid of maintaining an ever-growing list of 'share' providers, replacing them with one share button that kicks off the 'share' action. The user only sees the sites that she actively uses. Note: we're actively working with Mozilla on the API, and the draft I have prepared has been agreed upon by both vendors. I've read through the Webapps charter, and I believe Web Intents fits the goals and scope of the WG. Goals * Promote universal access to Web applications across a wide range of devices. - Web Intents can be implemented in browsers on all devices, and more importantly, the feature is a perfect conduit for hooking into platform functionality (Android Intents, iOS API, a scalable registerProtocolHandler). * Promote creation of tutorials and other educational material. - Check out http://examples.webintents.org where we have example clients/providers of Web Intents using a JS shim that works across all current browsers. - The action string in the API is suggested to be a URL pointing to documentation for the action, e.g., http://webintents.org/share is both the string for the 'share' action and the URL of the documentation for said action. Scope * Markup vocabularies for describing and controlling client-side application behavior. - Web Intents provides an intent tag that allows provider sites to declare which intent actions they handle. * Programming interfaces for client-side development: platform interaction. - As stated above, this feature can easily be extended to hook into the platform to, say, allow the UA to notify providers of platform events or data sources, e.g., plugging in a camera. The developers of this API, from both Mozilla and Google, believe Webapps is the right home for Web Intents. I'd like to open discussion on the topic and get your feedback. Ultimately we'd like to take the next steps towards getting Web Intents officially out in the open, actively developed by the larger Webapps community. Thanks, James Hawkins [1] http://dev.chromium.org/developers/design-documents/webintentsapi
