Re: Puzzled by the demos

The client app doesn't crawl the web, but I am maintaining an index of
intents that through the registry at http://registry.webintents.org/

When you visit a site or app that has the intent tag on the page, the UA is
supposed to popup a notification asking the user if they want to install
this application as a handler for that action (the shim just does this
silently).  Once it has been accepted, the registration for that site is
maintained and presented to the user when startActivity is called.

The examples at demos.webintents.org provide the startActivity and the
<intent> registration so to give users an example without having to go to
an external app to register the intent.

On Mon, Feb 13, 2012 at 10:21 PM, John J Barton <johnjbarton@johnjbarton.com
> wrote:

> On Mon, Feb 13, 2012 at 1:50 PM, Charles Pritchard <chuck@jumis.com>
> wrote:
> > On 2/13/2012 11:02 AM, John J Barton wrote:
> >>
> >> On Mon, Feb 13, 2012 at 10:51 AM, Paul Kinlan<paulkinlan@google.com>
> >>  wrote:
> >>>
> >>> I added Content Security Policy to the shim and a lot of the demos have
> >>> stopped working in FF until I get that fixed.
> >>>
> >>> wrt Chrome right at this moment you need to install apps from the CWS
> >>> first
> >>> - Ideally this would never be the case because we can detect apps via
> the
> >>> presence of a tag.
> >>
> >> I was hoping the demo would clarify the intro page:
> >>
> >>     Services register their intention to be able to handle an action
> >> on the user's behalf.
> >>
> >> Where are these 'services' ? On web sites? On pages in the users
> >> browser? Chrome apps? How do they get registered?
> >>
> >> The other question I was hoping to answer by inspecting the demo:
> >>
> >> What web pages / iframes are involved in the overall process?
> >>
> >
> > Services are on websites, found via <intent> tags in the content body.
>
> Sorry I must be misunderstanding.   I don't suppose client web pages
> with intent-consuming requirements are going to crawl the web looking
> for providers. So how do the <intent> tags on websites get to the
> client web page?
>
> >
> > Chrome just went through some updates (hello unstable!) which may make
> > things a little more confusing.
> >
> > In Paul's shim, he scans for intent tags,
>
> I'm trying to make sense of this. I guess you mean: For the purpose of
> the demo, Paul scans intent tags on the ... the demo page?
>
> > submits them to a session-based
> > page, and adds a JS shim for various methods. When intents are invoked,
> the
> > session based page pops up with a list of items that match the
> invocation.
> > You select an item, and it handles all of the postMessage dynamics.
> >
> > Frame (a) registration via <intent>, saying which intents are supported
> by
> > which page..
> > Frame (b) intent registration shim. Frame (b) would normally be handled
> by
> > the browser, natively.
> > The user keeps on trucking until they reach frame (c); a page which
> invokes
> > an intent, such as share.
> > They activate that invocation which pops up Frame (d), an intent selector
> > shim. Frame (d) would also be part of the browser.
> > They use that intent selector, which will pop up frame (e), possibly the
> > same url as frame (a), certainly the same domain.
> >
> > Communication happens, a message is handled to connect frame (c) and
> frame
> > (e).
> >
> > -Charles
> >
>



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