Re: A simpler, webbier approach to Web Intents?

On Thu, Feb 16, 2012 at 5:56 PM, Greg Billock <gbillock@google.com> wrote:
> On Thu, Feb 16, 2012 at 2:15 PM, John J Barton
> <johnjbarton@johnjbarton.com> wrote:
>>> We explicitly support passing any structured-cloneable type in intents
>>> payload. This includes Blobs and other file-ish types, ports, and
>>> esoterica not yet invented. :-)
>>
>> Then how do you have an advantage over postMessage() over MessageChannel?
>
> I was just clarifying that we do not intend to allow passing of a
> narrower range of types than would be possible with postMessage in
> page-to-page situations.

On the one hand you claim that web-intents is better because it does
not allow specifying complex communications. Then it's better because
it can. I'm sure it's better, but being clear on why is important.

So: In the communications layer, web-intents makes MIME data
transmission simple but allows any structured-cloneable types,
including those types of messages sent over postMessage.

>
> There are many situations, though, where it is preferable to pass MIME
> types, allowing the user to use a wider range of tools to handle the
> intent. Imagine invoking a local image editor, for instance, or being
> able to invoke a web site with a button on your photo download
> software to share a photo.
>
>>
>> The part that is missing is how a user who wants to complete a task
>> finds the web page with the corresponding <intent> tag so the service
>> can be registered.
>>
>> Based on your description it sounds like web-intent services have some
>> of the properties of bookmarks (remembered pages) and cookies (the
>> page isn't explicitly what the user is saving). Is that correct?
>>
>> So you are counting on users to go around building up a list of useful
>> services before they need them?
>
>
> Ah, I see. Yes, that is a major issue. It is hard to address it
> directly in the spec, since it isn't strictly a technological problem,
> and also because we think that a lot of the task of solving it is best
> left up to the user agent. We've definitely thought about it, and it
> is a common concern of publishers. There's a couple features of the
> draft that directly address this.
>
> First, using a declarative registration syntax makes developing a
> registry of services a lot easier. I'm familiar with the operations of
> one search engine which is capable of creating such an index, but
> making that process accessible is a design goal that went into
> motivating declarative registration. Additionally, leaving this
> process up to the browser means that registration can be quite
> light-weight, meaning users are more likely to have surfed by services
> they'll use by the time they want to use them to complete an intent.
>
> Second, we plan on exposing registered apps in the Chrome Web Store
> which provide intents functionality as a way to solve this discovery
> problem. We think that since all the data is kept locally, we can do a
> good job of combining server-side search for qualifying services with
> the user's bookmarks in a way to have a really good chance of
> surfacing good suggestions for the user.
>
> Third, we are contemplating a change to the draft to include the
> ability for publishers/clients to include suggested services to the
> picker. This is included in James Hawkins' most recent mail to WhatWG.
> [1]

Why wouldn't I race James to create WorldsMostAwesomeWebIntents page
full of <intent> tags?
Won't people be motivated to create ad supported lists? Won't users be
bombarded with <intent> pages?
I guess these are problems you'd love to have.

> You can try this out in the current Chrome beta and developer channel,
> if you're interested in seeing how we think this will work.

I've seen the demo live. It's very cool; that's is why I posted my questions.

>
> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-February/034881.html

Is this the correct reference? It seems to be some completely
different and uninteresting topic.

Thanks for your answers. You're convincing.

jjb

Received on Friday, 17 February 2012 02:38:45 UTC