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

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