WebIntents with links

[Thinker K.F. Li]

I have read article about WebIntents posted by Ben Adida and some
other related pages. I find current proposal is to start an intent
by calling functions. I feel it is not quite right. Maybe we should
make WebIntents more like URL links/hyperlinks. For example,

<a href="intents:addressbook?name=XXX&linkback=my-url">...</a>

When the user clicks on the link, the intent will be issued.
Then, intent services should redirect the request to a proper page
that can handle the intent. When the intent handler finish the task,
it loads the page given by "linkback" param to report status and data.

For applications that wants more programmable way, they can load
intents in frames or iframes, hidden or visible.

This way is more declarative than imperative. I think it makes intent
more easy to use.

[Jason Miller]

That only works well for intents that follow a fire and forget pattern,
where a standard URL would have normally applied.
If you have a use-case for using the href attribute to invoke intents, why
not build a shiv? Something like this:

//---
function handleIntentURI(uri) {
var type = uri.substring(0, uri.indexOf(':')),
args = uri.substring(type.length+1).replace(/^\?/g,'').split('&'),
params = {},
i, j, intent;
for (i=args.length; i--; ) {
j = args[i].indexOf('=');
params[decodeURIComponent(args[i].substring(0, j))] =
decodeURIComponent(args[i].substring(j+1));
}
intent = new Intent("http://webintents.org/"+type, "application/json",
JSON.stringify(params));
navigator.startActivity(intent);
}
document.addEventListener('click', function(e) {
var t=e.target, h;
do {
if (t.nodeName.toLowerCase()==='a') {
h = t.getAttribute('href');
if (h.substring(0,7)==='intent:') {
handleIntentURI(h.replace(/^intent:\s*/g,''));
e.preventDefault();
return false;
}
break;
}
} while((t=t.parentNode) && t!==document.body)
});
//---

Note the issues with trying to represent intents as links: you don't know
the content-type, or what format to use for the parameters. Perhaps
"content-type" could be added as one of the urlencoded parameters, but it
would cause naming conflicts.

It might be worth investigating how the URI is formed, namely adding a
section for the content-type. If the rest was then based off the format of
a data-URI, there would be enough information to construct a logical intent
from the simple string:

intent:share:text/uri-list,name=XXX&linkback=my-url

Just a thought.

- Jason

[Thinker Li]

On Sunday, March 18, 2012 3:19:30 AM UTC+8, Jason Miller wrote:
> That only works well for intents that follow a fire and forget pattern,
> where a standard URL would have normally applied.
> If you have a use-case for using the href attribute to invoke intents, why
> not build a shiv? Something like this:

...... cut ......

We can build link styles intents with API style implementation. It is also true to build intent API from link style implementation with a new frame or window. For example,

<a
href="intent:camera:linkback=my-url"
target="camera_window">...</a>

Caller can wait for intent by waiting for calling back from the page given by "linkback".

funciont callparent() {
window.opener.take_a_picture(picturedata);
}

document.addListener("onload", callparent);

> It might be worth investigating how the URI is formed, namely adding a
> section for the content-type. If the rest was then based off the format of
> a data-URI, there would be enough information to construct a logical intent
> from the simple string:
>
> intent:share:text/uri-list,name=XXX&linkback=my-url

Following your idea, maybe, "linkback" should be before first named parameter:

intent:share:text/uri-list,my-url,name=XXX

[Thinker Li]

On Sunday, March 18, 2012 3:19:30 AM UTC+8, Jason Miller wrote:

> That only works well for intents that follow a fire and forget pattern,
> where a standard URL would have normally applied.
> If you have a use-case for using the href attribute to invoke intents, why
> not build a shiv? Something like this:

...... cut ......

We can build link styles intents with API style implementation. It is also true to build intent API from link style implementation with a new frame or window. For example,

<a
href="intent:camera:linkback=my-url"
target="camera_window">...</a>

Caller can wait for intent by waiting for calling back from the page given by "linkback".

funciont callparent() {
window.opener.take_a_picture(picturedata);
}

document.addListener("onload", callparent);

> It might be worth investigating how the URI is formed, namely adding a
> section for the content-type. If the rest was then based off the format of
> a data-URI, there would be enough information to construct a logical intent
> from the simple string:
>
> intent:share:text/uri-list,name=XXX&linkback=my-url

[Jason Miller]

I'm wondering what the linkback URL would be used for, particularly in the
case of a single-page application (I think that'd be a large group of
mobile apps built using web technology). I think I understand this for a
flow that involves leaving the application (or page), performing an action,
and then redirecting back - but what about something that triggers a modal
action? I am thinking it might make more sense to use an event for that
situation, saving the page unload/reload time.


Jason Miller
519.872.0797 // developIT <http://developit.ca/> // Jason Miller
Design<http://jasonmillerdesign.com/>
*Developer of amoebaOS <https://amoebaos.com/>,
Shutterborg<http://shutterb.org/> &
more

*

On Sun, Mar 18, 2012 at 2:24 AM, Thinker Li <think...@gmail.com> wrote:

> On Sunday, March 18, 2012 3:19:30 AM UTC+8, Jason Miller wrote:

> > That only works well for intents that follow a fire and forget pattern,
> > where a standard URL would have normally applied.
> > If you have a use-case for using the href attribute to invoke intents,
> why
> > not build a shiv? Something like this:

> ...... cut ......
>
> We can build link styles intents with API style implementation. It is
> also true to build intent API from link style implementation with a new
> frame or window. For example,
>
> <a
> href="intent:camera:linkback=my-url"
> target="camera_window">...</a>
>
> Caller can wait for intent by waiting for calling back from the page given
> by "linkback".
>
> funciont callparent() {
> window.opener.take_a_picture(picturedata);
> }
>
> document.addListener("onload", callparent);
>

> > It might be worth investigating how the URI is formed, namely adding a
> > section for the content-type. If the rest was then based off the format
> of
> > a data-URI, there would be enough information to construct a logical
> intent
> > from the simple string:
> >
> > intent:share:text/uri-list,name=XXX&linkback=my-url
>

> Following your idea, maybe, "linkback" should be before first named
> parameter:
>
> intent:share:text/uri-list,my-url,name=XXX

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Mounir Lamouri]

On 03/17/2012 05:56 PM, Thinker K.F. Li wrote:
> I have read article about WebIntents posted by Ben Adida and some
> other related pages. I find current proposal is to start an intent
> by calling functions. I feel it is not quite right. Maybe we should
> make WebIntents more like URL links/hyperlinks. For example,
>
> <a href="intents:addressbook?name=XXX&linkback=my-url">...</a>
>
> When the user clicks on the link, the intent will be issued.
> Then, intent services should redirect the request to a proper page
> that can handle the intent. When the intent handler finish the task,
> it loads the page given by "linkback" param to report status and data.
>
> For applications that wants more programmable way, they can load
> intents in frames or iframes, hidden or visible.

If we take into account that intents can take data or not and can return
data or not, this would work very well only for intents that do not take
data and do not return data. That seems to be a serious subset of intents.
If the developper wants to send data with the intent or take back data,
he/she will have to use a lot of JS to do so and that would be much more
annoying than the current proposed API.

Also, I'm not taking into account intents that might want to discuss
with the caller while running, that would be a hell to handle with that
solution. This said, I'm not really sure if those intents really exist...

--
Mounir