W3C home > Mailing lists > Public > public-web-intents@w3.org > January 2012

Re: Is there an existing mechanism that can be used for WebIntents?

From: Mike Kelly <mikekelly321@gmail.com>
Date: Thu, 19 Jan 2012 20:56:04 +0000
Message-ID: <CANqiZJa716m0jZgrwbcnnHf3TCqVGvoG8ECHoehc6mGOq7Y8BQ@mail.gmail.com>
To: Paul Kinlan <paulkinlan@google.com>
Cc: James Hawkins <jhawkins@chromium.org>, public-web-intents@w3.org
On Thu, Jan 19, 2012 at 5:15 PM, Paul Kinlan <paulkinlan@google.com> wrote:

> On Thu, Jan 19, 2012 at 8:54 AM, Mike Kelly <mikekelly321@gmail.com>
> wrote:
> >
> >
> > On Thu, Jan 19, 2012 at 4:34 PM, James Hawkins <jhawkins@chromium.org>
> > wrote:
> >>
> >> There are a few drawbacks with using the link element.
> >> * link must appear in the head and is a void element.
> >>   - This prevents the use case of the service site providing alternative
> >> UI if <intent> is not supported: <intent ...>Intents are not supported!
> >>  Check out this work-around</intent>
> >
> >
> > Both of these issues are worth exploring with html5 working group, more
> than
> > happy to get involved on this.
> >
> >>
> >> * In the current syntax you provided, how would the UA know this is an
> >> intent registration?  Per the spec, |action| is just a string; we use
> URLs
> >> to set precedence as a developer-friendly way of documenting the action.
> >
> >
> > Presumably UAs only react to the @action tokens they understand? Using
> link
> > will provide them with a slightly larger set of elements to go through to
> > find these, which should not present an issue - am I missing something
> here?
>
> An intent action string can be any string - it is simply a token that
> the client and service agree to use to discover each other and have an
> accepted basic protocol for data exchange - an enterprise application
> that never sees the light of day on the open internet could define
> "fluffykittens" as an action name (although that would be a terrible
> name) and as long as their client and service applications used
> fluffykittens they would be able to discover each other.
>

Yep absolutely, this is exactly how link relations work too.


>
> >
> >>
> >> * We'd have to change the HTML parsing algorithm.
> >>
> >
> > I'm not au fait with the implementation here, is this a significant
> > undertaking?
> >
> >>
> >> Can you share your objections to using the <intent> element?
> >
> >
> > It is, ostensibly, a link.. so why not expose it as one? There is a lot
> of
> > existing web infrastructure that is already geared up to work with links.
> > e.g. atom has a link element, we have the Link header in HTTP, and links
> and
> > relations are already familiar to developers.
> >
> > Linking is a very 'web' thing, so re-using <link> would make web intents
> > 'fit in' better with the rest of the web.
>
> It doesn't have to be a link, absence of a link infers the current
> page.


href is not a required property of <link> in HTML, so this is not an issue.


> Added to this, the remote page has no need to be fetched which
> the <link> element is meant to acheive, i.e, this page enhances the
> current page - the intent href semantically doesn't mean this.


I'm not sure what you mean - I think this is a distinction you are drawing
yourself rather than one that is specified anywhere? Is there something in
the html spec you are basing this on?

Cheers,
Mike
Received on Thursday, 19 January 2012 20:56:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 January 2012 20:56:40 GMT