Re: Web Intents - Suggested Deliverables (part 2)

The link to where the intent data is might behind a user-access
restricted login which then excludes indexers from being able to
understand what the actions the page supports.

Link rel="intent" will require a 2nd fetch to potentially other page
from a users UA, which might be access controlled, or expensive to
render, or from an analytics point be wrong.  Loading that extra
application page just to understand what it does is wrong.

The next step in most peoples thinking from above statement is that
ink rel="intent" should point to a central manifest file.  For this we
see a number of problems and I want to discount a manifest file as
early as possible from the solution:

1. its another file to manage and deploy
1a. history of appcache deployment issues, maintenance and developer experience
1b. It hasn't got the copy and paste-ability that a plain tag has.
2. the semantics around what to do with changes is very complex
2a. If an item is removed from the manifest is it removed from the UA?
2b. If manifest 404s or faults do we remove all installed intents
3. general syntax issues.  What should the syntax be, xml, json, or
text - we already have multiple different file types for developers to
grok

On the subject of changing urls and types:  I do fully expect the page
that handles the action to have the tags of the intents it intends to
support, the UA can then validate if the invoked actions can be
handled by the page, if not cause a processing exception and either
let the user remove the action OR choose another action.  This will
handle cases of UA change to location of the action - when the action
page no longer handles the intent or 404's the user can re-pick or
remove; and if the type changes in the page, ie, if the service now
changes from supporting text/uri-list -> image/png, the UA will know
that the page being called can't handle it and again re-prompt.

The good thing about this is that if you become less specific say from
image/png -> image/* or even * then the action will still be valid.

On the other point of the meta tag.  The example provided (and I know
it was just an example) doesn't easily allow for one app or page to
have multiple intents listed, and this was another large issue for not
using them.

P


On Tue, Nov 22, 2011 at 10:22 AM, Robin Berjon <robin@berjon.com> wrote:
>
> On Nov 22, 2011, at 02:56 , Paul Kinlan wrote:
> > Yes we discussed the intent tag on public-webaps [1], or at least the
> > reason about it be declared in the html over a manifest file.
> >
> > I don't believe the meta element was directly discussed, but the
> > reasoning behind our choice of new tag is: 1) it is a new platform
> > feature with elements and attributes that don't fit in the meta name
> > and content model
> > 2) encoding data into the content attribute is error prone
> > 2a) parsing data encoded in the content attribute will be error prone
> > 3) if we chose not to encode, we would introduce a lot of extra
> > attributes that are very specific to one case
> > 4) it can be validated by parsers and by eye with greater ease
> > 5) a separate DOM element can have those properties exposed
> > individually via scripting, for instance there would be a
> > DOMIntentElement that can be compared as an instanceof and also have
> > access to the specific attributes.
> >
> > [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1518.html
>
> I don't want to rathole into syntax right at the start but there's one thing that bothers me: the <intent> element is defining authoritative processing metadata for *another* resource. That seems like an excellent recipe for screwing up.
>
> Consider this scenario: I am developing a site for Cryptozoology Anonymous, and include a service which allows to report sightings of unicorns and dahuts. That service sits at http://cryptonymous.org/report.html. I link to it from another page using:
>
>    <intent action="http://example.org/report" type="text/plain" href="report.html"/>
>
> Over time, I realise that it's more convenient if I add that link to multiple pages on my site.
>
> Later, I reckon that text descriptions of sightings aren't all that reliable for some reason, and switch to accept image/*. I also note that it's nicer to inline the service page rather than open it in a new window. So I change my implementation completely, and update the links to be:
>
>    <intent action="http://example.org/report" type="image/*" href="report.html" disposition="inline"/>
>
> But of course, I forget a bunch of those. We now have intent registration links that are out of synch, for no gain and no good reason (that I can see) whatsoever. Or have I missed something (which is entirely likely)?
>
> Detaching information that has a direct bearing on processing from the place where the processing occurs is generally a bad idea; the media type system is a good example of how wrong that can go.
>
> If we rework this to have pages just linking to the service, and processing data in the service itself, we can have pages linking with:
>
>    <link rel="intent" href="report.html"/> (or "service")
>
> And then in report.html:
>
>    <meta name="intent-action" content="http://example.org/report"/>
>    <meta name="intent-type" content="image/*"/>
>    <meta name="intent-disposition" content="inline"/>
>
> Note that I'm not married to the above syntax, and the latter set of meta might still be best captured by and intent element (especially if there are good UCs for having an HTMLIntentElement). But at least it separates linking to an intent service from defining what that service's interface, which IMHO is a win.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>



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

Received on Tuesday, 22 November 2011 12:01:55 UTC