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 a scheme register with RPH
>> RCH etc.
> The proposal I put forward does not have this problem.

Ian, the proposal you put in goes a bit far with "kind":

navigator.registerIntentHandler(intent, filter, url, kind);
"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"

I'd rather see that entire problem handled by the UA.
It's the UA that prompts the user on what they want to do.

Those questions look like something a UA would ask the user,
not something the author would specify.


>> 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) };

Intent isn't so bad, and it's a little different than postMessage, 
otherwise it'd be postMessage.

canvas.toBlob(function(blob) {
  var port = new WebIntent('share', blob.type, blob);
  port.startActivity(function(event) {
   doSomethingMaddening(event);
  });
});


WebIntent seems a reasonable long-term glue for FileSaver and WebSockets.

If I have a PNG file, I might want to "save" it to a network drive, or 
disk, "send" it to a space, a book
or some kind of whacky cloud printing service; push it over to another 
web app or shared thread, or
post it via http, or web sockets.

Let me do all of that as a user, and have some management over it in the UA.


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

This is where the FileSaver API has a wealth of events in its vocabulary.
The task here is the task of picking what intent the user wants to run.

Let's talk about FileSaver again; UAs have realized that even saving a 
file ought to be processed by the user.
Thus we have Google's "Keep/Discard" selection. That's a closer analogy 
than postMessage which has no user interaction.

FileSaver events may be appropriate here.


>>>> 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?
>> We want to index and discover these apps so that we can provide a way to
>> offer suggested apps if the user doesn't have an app already installed.
> That is an interesting use cae.
>
> Are you interested in providing the same kind of functionality for scheme
> and content type handlers?

Presently, Mozilla and Google seem to be heading into <link rel> 
pointing to a manifest file; and that file exposes the functionality in 
JSON.

It's more likely that those manifest files and headers would appear, and 
be indexed than would <intent> tags.

Can we use <link rel> instead of <intent>? They're already getting added 
into link rel, via package manifests.


>> We believe we have more flexibility with how we present registration of
>> intents to user by using a declarative markup.  The UA will be able to
>> batch up and aggregate requests to the user to install intents more
>> easily if they are present in the DOM than if there were arbitrary
>> individual requests to a register API.
> There is no difference on this front. There's no reason an API call
> couldn't be batched up too.

Just as easy to present them in manifest.json, via CRX-less Web Apps in 
Chrome, or other similar method in Mozilla and other vendors.

That said, it's interesting that one could potentially create an 
"installer" directory, with lists and lists of intents to register and 
de-register.
A register API would be a good thing, for that use case.

Add registerIntentHandler(args) to a queue, wait until the end of the 
event loop, pop up the UA request,
ignore further calls until that UA request has completed.

Web Apps are going to have formal manifest files, they'll likely have 
already requested various types and those manifests are accessible to 
search engines.
If there really needs to be a microformat in HTML on the page, <link 
rel> seems like a good semantic for it instead of introducing a new tag.


>>> Adding new elements (especially to<head>) is a high-cost affair and
>>> should be avoided unless there are really good reasons for it.
>> Sorry, in what sense?  In specification terms or implementation and
>> performance terms?
> All three, as well as testing.

It's important that these can be indexed, that there is a specified method.
I don't think adding a new element is necessary for indexing.

>>>> Unregistering would be handled by the UA's management interface
>>>> directly by the user.
>>> So how does a site that has stopped providing a feature unregister its
>>> handler for that feature?
>> I would be surprised if apps use any unregister feature.
> We've received requests -- including from Google! -- to allow sites to
> unregister content and protocol handlers. I see no reason to think it
> would be different here.
>

Many applications provide users with an options screen, to turn on and 
off various features.

When a user wants to turn off a security sensitive feature, they're 
telling me they want to unregister the security credentials from the 
computer.
Whether they're OAuth credentials, or file system access, the user wants 
them disabled.

Currently, in Chrome unregister protocol handler is buried three panels 
deep in the settings menu.
It's a fairly technical process to navigate the settings menu in a UA/OS 
for handling.

I'll be using the unregister methods when they appear.



>> The temptation would be to port.postMessage(data);
>> port.postMessage(data); and in this case what should happen in the app.
> That's entirely up to the definers of the protocol for that action.
> Indeed, if, as you point out, you can pass a port to the other side as
> part of the data anyway, the exact same problem exists with your current
> API. It's just simpler to do in the proposal above.
>

They're both simple APIs and use structured clone algorithm specs for 
their raw power.

Fall back verbs would be useful in case one intent isn't registered, but 
a standard is.

This would try the first verb, and if nothing is registered, or the user 
wants to move on, it'd show the items registered to the second:
intent = WebIntent('com.example.photo-tagging share', blob.type, blob);

I'd like to see that picked up.

If the ports semantic from postMessage is also picked up, I'd like to 
see it withheld if the first service specified is not available.
In my example, a UA falling back to "share", would not transfer ports, 
just the blob.

Received on Friday, 23 September 2011 00:22:21 UTC