Re: A simpler, webbier approach to Web Intents?

On Thu, Feb 16, 2012 at 12:01 PM, John J Barton
<johnjbarton@johnjbarton.com> wrote:
> On Thu, Feb 16, 2012 at 11:21 AM, Greg Billock <gbillock@google.com> wrote:
>> On Thu, Feb 16, 2012 at 8:29 AM, John J Barton
>> <johnjbarton@johnjbarton.com> wrote:
> ...
>>
>> The web-messaging concept that ports can be capabilities-driven
>> channels to provide applications the ability to loosely couple is one
>> that's very similar to the goal of web intents. The central nub of
>> that problem, however, isn't the communication mechanism, it is the
>> format of the messages and the service discovery mechanisms.
>
> All are needed for a complete solution.
>
>> Those are
>> the problem facets web intents starts with. We also think the problem
>> needs to be scoped to include loosely coupling web apps with
>> browser-initiated and local system-initiated events. Starting with
>> those concerns, I don't think messaging channels are the most natural
>> solution. Messaging channels are a solution if the problem is "how
>> could we possibly arrange arbitrary communication between two web
>> pages."
>
> I agree with the gist of your point, but to be precise, it's "limited
> bi-directional JSON message communication".
>
>> But the problem web intents is trying to solve is more
>> structured: "how can web applications participate in fulfilling a
>> single user-oriented task."
>
> To be realistic, web-intents arranges for "uni-directional
> string-augmented MIME type communications".

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

Or do you mean that it is hard to specify such objects with MIME types?

> If we all lucky the communications will fulfill a task. The primary
> and important advantage of the web-intent approach is that the tasks
> allowed by the communications are simple to characterize and MIME
> types describe digital properties interesting to many users.
>
> If the user-oriented task involves interactivity or non-MIME data,
> then their task won't be fulfilled.
>
> I want to be clear: I'm not arguing against your choices, they make
> sense to me. Your description is just unclear.

I'm definitely eager to refine the description to make it more clear! :-)

>>
>> What's more, if it turns out that establishing message channels is
>> really valuable, the web intents API is so simple it's going to be a
>> good solution for solving the registration/establishment problem
>> there:
>>
>> var channel = new MessageChannel;
>> navigator.startActivity(new Intent("http://webintents.org/connect",
>> "type-of-service-I-want", channel.port1));
>>
>> The web intents proposal explicitly wants to support this kind of use.
>
> Cool, so all I am suggesting is that you adopt the strategy of
> co-opting the postMessage crowd by defining a polyfill/shim based on
> postMessage().

We have shim code that Paul Kinlan has developed and is hosted on
webintents.org. That code currently doesn't use postMessage for
several reasons he can elaborate more on. (An earlier iteration did
explore using postMessage.) The basic problem is that we want to use
the 'window.intent' delivery mechanism in order to essentially make
the declarative registration mechanism gate delivery. Our earlier
conception allowed that to go in <head>, but that's not going to work.
That change may make it possible to go back to the postMessage shim.
Paul? What do you think? I know there were several issues with that
(and possibly still are).

>> We, the authors, think that more structured intents will end up being
>> more valuable, but we're explicitly in favor of allowing generic
>> connection establishment to exist alongside those more structured
>> intents. In addition to being very compact and developer-friendly,
>> this mechanism brings along all the semantics of user selection,
>> assumed support for defaulting and automation, dynamic extensibility,
>> and so forth that are already part of web intents.
>
> You must be reading something other than http://webintents.org/ ;-)
>
>>
>>> More important than haggling about the lower level issues it seems to
>>> me that a clear and complete story for service registration and
>>> discovery is missing.
>>
>> Do you mean that a proposal for discovery and registration of these
>> ports as above is missing?
>
> No I mean that your proposal for web-intents registration and
> discovery is vague and incomplete.
>
>> I agree with that, but I think our proposal
>> for registration and discovery of web intents service is quite
>> concrete (concrete enough to actually be implemented!).
>
> Well here we disagree because I couldn't figure out how to even start
> implementing your proposal.

Hmmm. There are checkins to webkit and chromium implementing the
entire thing. The only gap is the <intent> tag from above, which
works, but is not agreed upon, and so is not checked in. I'm creating
both the changes and the proposal, so there's an obvious suspect:
there may be information in my head that isn't in the draft. :-) If
that's so, I'm eager to fix it. Tell me what's ambiguous or hard to
follow. There could absolutely be points that aren't spelled out as
well as they should be, as the spec is still under discussion, but I
do intend for it to be possible to create a sensible implementation
given what's there now.

The content-based component of registration is the <intent> tag, which
then triggers calls into the browser to present whatever registration
mechanism you want to use. (See [1]) In Chromium, we're using an
infobar (see [2]) and a registry backed by a table in our SQLite
database. Those are implementation details, however. We also have an
extension/app registration mechanism, using the "intent" property of
the manifest.

Is that the part you're having a hard time following? The draft spec
covers this is at [3].


[1] https://bugs.webkit.org/show_bug.cgi?id=73039
[2] http://code.google.com/p/chromium/source/search?q=intent+infobar&origq=intent+infobar&btnG=Search+Trunk
[3] http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#registration-markup


> jjb
>
>> And as above,
>> I think it ends up being a good solution for discovery for
>> establishing these channels, if you wanted to build that.
>>
>> -Greg
>>

Received on Thursday, 16 February 2012 21:50:19 UTC