Re: A simpler, webbier approach to Web Intents?

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

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.

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

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 20:02:10 UTC