Web Intents | Hacker News Reader

Web Intents

webintents.org

67 pointstelemachos21 comments

http://news.ycombinator.com/item?id=2722549

There seems to have been little if any change since then.

This is mostly an official announcement of the project in chrome

Shouldn't this be handled by ordinary links with protocols?

"mailto:" is a protocol that is interpreted by the user agent, to launch the user's preferred mail client. We could also have "share:", to launch the user's preferred way of sharing things.

So why not this?

    <a href="share:http://sample.com/url/">Share this</a>

It's a bit odd to have the protocol wrapping what looks like another protocol, but it's legal. One might even have the convention that an empty share means the current url. Then it would be just

    <a href="share:">Share this</a>.

It breaks down when you need to pass rich data. Images, videos, and JSON for example.

What is not rich with http://sample.com/url/ ?

The URL could point to an image, a movie, a web page, JSON, etc. The only thing it does not make easy/practical is passing large data chunks inline.

That requires additional work from the Intent providers. They can no longer be pure JavaScript if they have to request data from other domains, it increases latency as you wait for requests to fetch the item to complete.

Why is it important that intent providers can be pure JavaScript? I would think most providers would be native programs or run in a browser.

As to the latency: if large data isn't available locally, someone will have to take a hit. I do not see why severing this to the provider would be problematic.

If it is available locally, I would hope that the intent provider can retrieve it from cache.

Also, deferring the loading enables optimizations. Suppose I see an image on example.com that I want to share using Flickr. If I send the URL to Flickr, it can retrieve the image from example.com using its fat Internet pipe. If, instead, I have to send the image, I have much more upstream data. Even at home, that can be problematic. Mobile, things are worse.

It appears Web Intents has taken the time-tested concept of an enterprise service bus (http://en.wikipedia.org/wiki/Enterprise_service_bus) and used it in a non-enterprise application - namely social networking / bookmarking.

Here's a few ways that makes this promising:

- Using a common set of standard services makes communication application-agnostic

- It reduces dependencies across applications - applications can change, but the services remain the same

- Innovation will be driven by features, not by adoption of one application's API vs. another application's API - this plays into Google's philosophy that innovation should ultimately prevail

Interesting stuff.

To whom ever might be listening and can do something about it: please use a JSON format and not an XML format for configuration files. Concision and aesthetics count. Thank you for your consideration :)

There is no XML. We have html that's about it.

We also specifically want to avoid any sort of configuration file (see problems with appcache)

Yes. Please, please, please. There is no reason sharing actions, etc., should not be handled by the user agent.

(I would also like to see browsers more closely support e.g. the big JS libraries like jQuery (UI) et al by having a local copy you can opt in to using instead of having the user download them yet again, but that's a separate dream.)

The latter is just better caching and using the CDNs, it's not really so much about building them in the browser.

"There is no reason sharing actions, etc., should not be handled by the user agent."

Wait, why stop there? Aren't there all kinds of actions that should be handled by the user-agent? There are N verbs that we could get excited about wiring up, across M potential service providers. Woo hoo!

Of course, once the enthusiasm for the shiny wears off, we don't really want to have to experience the web this way. Do we?

I sure do!

Reminds me of old Sun RPC Directory.

or UDDI http://en.wikipedia.org/wiki/Universal_Description_Discovery...

Paul, what's the story behind the fairly different sites [1], [2] and [3]?

  [1] http://webintents.org/
  [2] http://www.webintents.org/
  [3] http://www.webintents.com/

The other post with the link to techcrunch also refers to this URL. So is this a google project then?

Yes. But we are working with Mozilla on it and will have a working group set up soon.

From an end user point of view this is terrible, I don't understand the point. Don't give me options, just do it!

Reply on news.ycombinator.com