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

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

I don't understand what action you're proposing we take here.  Can you
elucidate this statement?


>  * 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?
>
>

Requiring UAs to keep a list of known action defeats the extensibility of
the feature.  Web Intents allows developers to create compelling
functionality for use cases we haven't dreamed yet.


> * We'd have to change the HTML parsing algorithm.
>>
>>
> I'm not au fait with the implementation here, is this a significant
> undertaking?
>
>

Yes, but more importantly adding a feature that requires changing the
parsing algorithm is met with stiff resistance from the community.


>  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.
>
>
Our thoughts differ on this point.  The intent element is a declaration of
functionality.  I see Paul's response now, and I was going to say the same,
but he said it more eloquently :-)

Thanks,
James


>
>>
>> On Thu, Jan 19, 2012 at 1:56 AM, Mike Kelly <mikekelly321@gmail.com>wrote:
>>
>>>  Hi Paul,
>>>
>>> Ok thanks, that being the case, what is the difference between <link> vs
>>> <intent> and @rel vs @action in the following example:
>>>
>>> <intent action="http://webintents.org/subscribe" type=".."  href=".." />
>>>
>>> <link rel="http://webintents.org/subscribe" type=".." href=".." />
>>>
>>> So, is it possible for web intents to simply re-use the existing,
>>> ubiquitous <link> instead of having to introduce <intent>?
>>>
>>> Cheers,
>>> Mike
>>>
>>> On Sun, Jan 15, 2012 at 6:23 PM, Paul Kinlan <paulkinlan@google.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> This was something that I started to document under
>>>> http://webintents.org/subscribe - the intents discovery mechanism in
>>>> the spec doesn't preculde a UA from detecting this and allowing the user to
>>>> invoke an action to subscribe to the feed using their preferred application.
>>>>
>>>> P
>>>>
>>>> On Fri, Jan 13, 2012 at 4:48 AM, Mike Kelly <mikekelly321@gmail.com>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I was wondering whether an example of 'web intent' behaviour has
>>>>> already existed for some time:
>>>>>
>>>>> The example I am thinking of is driven by atom/rss links in the head
>>>>> of HTML pages, i.e. an html page containing the following link in the
>>>>> head of the document..
>>>>>
>>>>> <link rel="alternate" type="application/rss+xml" href="...." />
>>>>>
>>>>> .... this causes a browser (e.g. Firefox) to present the user with the
>>>>>
>>>>> option to 'Subscribe to This Page' where the user can fulfil their
>>>>> 'subscription intent'.
>>>>>
>>>>> Would this be considered an equivalent of a web intent?
>>>>>
>>>>> Cheers,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Paul Kinlan
>>>> Developer Advocate @ Google for Chrome and HTML5
>>>> G+: http://plus.ly/paul.kinlan
>>>> t: +447730517944
>>>> tw: @Paul_Kinlan
>>>> LinkedIn: http://uk.linkedin.com/in/paulkinlan
>>>> Blog: http://paul.kinlan.me
>>>> Skype: paul.kinlan
>>>>
>>>>
>>>
>>
>