RE: A simpler, webbier approach to Web Intents?

*        Could a web page or web app include a list of services to be added to the list of available services for various Intents?

*        Can intents services be embedded in ads that come from an ad network and are inserted into web pages?

*        Can an intent service be pre-selected by the page or by client settings so that the choice does not have to impact the user each time?

*        Can a service provider have an intents services function which could be pushed to a browser?

Thanks!
-Paul

Q me<qto://talk/pg2483>


From: Paul Kinlan [mailto:paulkinlan@google.com]
Sent: Tuesday, February 21, 2012 11:14 AM
To: John J Barton
Cc: Rachel Blum; Greg Billock; public-web-intents@w3.org
Subject: Re: A simpler, webbier approach to Web Intents?

Kind of.

The user would accumulate entries on the sites that they visit, and these are the apps that are then registered, this is where the user grants the ability for the service to fulfill the intent.  The user to would not have to click install in the IDE at all, the user in the IDE would just request a service from the browser.

There are other ways of finding services too, the current shim maintains a registry of publicly accessible services that support intents and can offer them to the user to invoke.

P

On Tue, Feb 21, 2012 at 3:53 PM, John J Barton <johnjbarton@johnjbarton.com<mailto:johnjbarton@johnjbarton.com>> wrote:
Ok, so I gather the idea is that a user will visit some sites that
have top-level pages with intent tags and, as a side effect, they will
accumulate entries in the registry. Then they would go to the IDE and
click "install" or something. Then the IDE would then request the
services it is programmed to consume and the user would select the one
they want from the list.

Is this correct?

jjb

On Mon, Feb 20, 2012 at 9:38 AM, Paul Kinlan <paulkinlan@google.com<mailto:paulkinlan@google.com>> wrote:
> Sorry to add to the confusion.  I only stated that registration couldn't
> happen via an iframe and it shouldn't.
>
> That is not to say we shouldn't have an iframe solution, I think we should
> and it shouldd be discussed and worked on here because I see Web Intents
> solving the negotiation problems that we see in all of the raw postMessage
> solutions, which is something the developer should not have to handle.  I
> believe Darin Fisher suggested something similar on this group a while ago
> [1].
>
> I spoke to someone a while ago about Orion and this was something we didn't
> have support for in Web Intents yet.  The closest we get is "inline"
> disposition which displays the launched app in the context of the old app.
>
> [1] http://lists.w3.org/Archives/Public/public-web-intents/2011Dec/0050.html
>
> On Mon, Feb 20, 2012 at 5:22 PM, John J Barton <johnjbarton@johnjbarton.com<mailto:johnjbarton@johnjbarton.com>>
> wrote:
>>
>> Oh, sorry. I ended up here after I asked on public-webapps about a
>> standard way to establish communications between cross-domain iframes
>> and a web page. Allowing plugin authors and plugin users to succeed
>> without negotiating with the framework authors is powerful advantage.
>> The use case, plugins for development tools, closely resembles
>> web-intents. The plugin API could be as simple as image exchange like
>> the memegen example (hence my interest in web-intents) or more
>> complicated exchanges requiring two way operations (hence my questions
>> about using postMessage).
>>
>> But iframes cannot participate in web-intents so we are out of luck.
>>
>> jjb
>>
>> On Mon, Feb 20, 2012 at 8:58 AM, Paul Kinlan <paulkinlan@google.com<mailto:paulkinlan@google.com>>
>> wrote:
>> > why?
>> >
>> >
>> > On Mon, Feb 20, 2012 at 4:38 PM, John J Barton
>> > <johnjbarton@johnjbarton.com<mailto:johnjbarton@johnjbarton.com>>
>> > wrote:
>> >>
>> >> Ok, thanks for the info. Sounds like we will have to look elsewhere
>> >> for a cross-domain application integration framework.
>> >> jjb
>> >>
>> >> On Mon, Feb 20, 2012 at 5:02 AM, Paul Kinlan <paulkinlan@google.com<mailto:paulkinlan@google.com>>
>> >> wrote:
>> >> > No.  The shim blocks all registrations from occurring inside an
>> >> > iframe.
>> >> >  I
>> >> > would expect the native implementation to do the same.  If the spec
>> >> > doesn't
>> >> > mention this, it should.
>> >> >
>> >> > On Fri, Feb 17, 2012 at 11:55 PM, John J Barton
>> >> > <johnjbarton@johnjbarton.com<mailto:johnjbarton@johnjbarton.com>> wrote:
>> >> >>
>> >> >> On Fri, Feb 17, 2012 at 3:41 PM, Rachel Blum <groby@google.com<mailto:groby@google.com>>
>> >> >> wrote:
>> >> >> >
>> >> >> >>
>> >> >> >> > Why wouldn't I race James to create WorldsMostAwesomeWebIntents
>> >> >> >> > page
>> >> >> >> > full of <intent> tags?
>> >> >> >> > Won't people be motivated to create ad supported lists? Won't
>> >> >> >> > users
>> >> >> >> > be
>> >> >> >> > bombarded with <intent> pages?
>> >> >> >> > I guess these are problems you'd love to have.
>> >> >> >
>> >> >> >
>> >> >> > Let's keep in mind that (unless I misremember) intent tags have a
>> >> >> > same-origin restriction on the action path.
>> >> >> >
>> >> >> > So you'll actually need to do a bit of work beyond just collecting
>> >> >> > tags
>> >> >> > on
>> >> >> > your page - unless you choose to provide no-op intents.
>> >> >>
>> >> >> I guess a page full of
>> >> >> <iframe src=<page-with-intent-tag>>
>> >> >> wouid work, right?
>> >> >>
>> >> >> jjb
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > Rachel
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Paul Kinlan
>> >> > Developer Advocate @ Google for Chrome and HTML5
>> >> > G+: http://plus.ly/paul.kinlan
>> >> > t: +447730517944<tel:%2B447730517944>
>> >> > tw: @Paul_Kinlan
>> >> > LinkedIn: http://uk.linkedin.com/in/paulkinlan
>> >> > Blog: http://paul.kinlan.me
>> >> > Skype: paul.kinlan
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > Paul Kinlan
>> > Developer Advocate @ Google for Chrome and HTML5
>> > G+: http://plus.ly/paul.kinlan
>> > t: +447730517944<tel:%2B447730517944>
>> > tw: @Paul_Kinlan
>> > LinkedIn: http://uk.linkedin.com/in/paulkinlan
>> > Blog: http://paul.kinlan.me
>> > Skype: paul.kinlan
>> >
>
>
>
>
> --
> Paul Kinlan
> Developer Advocate @ Google for Chrome and HTML5
> G+: http://plus.ly/paul.kinlan
> t: +447730517944<tel:%2B447730517944>
> tw: @Paul_Kinlan
> LinkedIn: http://uk.linkedin.com/in/paulkinlan
> Blog: http://paul.kinlan.me
> Skype: paul.kinlan
>



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