Re: A simpler, webbier approach to Web Intents?

On Thu, Feb 16, 2012 at 1:49 PM, Greg Billock <gbillock@google.com> wrote:
> 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. :-)

Then how do you have an advantage over postMessage() over MessageChannel?

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

I'm not saying anything about 'hard'. I'm just trying to describe
web-intents communications so we can compare it to other solutions.

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

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?

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

I think it would be very helpful if your reference [3] were mentioned
on webintents.org under Specifications.   As I said, I was going on
the content of page.

jjb

>
>
> [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 22:16:10 UTC