5 ms·
Web Intents
- allad 15y agoReminds me of old Sun RPC Directory.
- dntbrme 15y agoor UDDI http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration http://en.wikipedia.org/wiki/Universal_Description_Discovery...
- masklinn 15y agohttp://news.ycombinator.com/item?id=2722549 http://news.ycombinator.com/item?id=2722549 There seems to have been little if any change since then.
- kinlan 15y agoThis is mostly an official announcement of the project in chrome
- yalogin 15y agoThe other post with the link to techcrunch also refers to this URL. So is this a google project then?
- kinlan 15y agoYes. But we are working with Mozilla on it and will have a working group set up soon.
- jsmcgd 15y agoTo 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 :)
- eddanger 15y agoFrom an end user point of view this is terrible, I don't understand the point. Don't give me options, just do it!
- brendino 15y agoIt appears Web Intents has taken the time-tested concept of an enterprise service bus (http://en.wikipedia.org/wiki/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.
- alanh 15y agoYes. 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.)
- StavrosK 15y agoThe latter is just better caching and using the CDNs, it's not really so much about building them in the browser.
- crabasa 15y ago"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?
- ori_b 15y agoI sure do!
- ez77 15y agoPaul, 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/
- neilk 15y agoShouldn'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>.
- abraham 15y agoIt breaks down when you need to pass rich data. Images, videos, and JSON for example.
- Someone 15y agoWhat is not rich with http://sample.com/url/ 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.
- abraham 15y agoThat 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.
- Someone 15y agoWhy 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.