Re:Web Intents
by neilk on Friday August 05, 2011 @04:49PM
(#2851701)
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.
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
Re:Web Intents
by abraham on Saturday August 06, 2011 @01:45PM
(#2854429)
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.
Re:Web Intents
by Someone on Sunday August 07, 2011 @07:06AM
(#2856392)
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.
Re:Web Intents
by brendino on Friday August 05, 2011 @02:01PM
(#2851009)
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
Re:Web Intents
by jsmcgd on Friday August 05, 2011 @12:18PM
(#2850590)
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 :)
Re:Web Intents
by alanh on Friday August 05, 2011 @02:29PM
(#2851124)
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.)
Re:Web Intents
by crabasa on Friday August 05, 2011 @04:41PM
(#2851676)
"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?
There seems to have been little if any change since then.
"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?
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 justThe 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.
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.
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.
(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.)
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?