Google Developing Master API — Web Intents

GeneralSecretary writes "Google is developing an API to allow web apps to easily share information with various services. Quoting: 'Android OS addresses this problem with Intents, a facility for late run-time binding between components in the same or different applications. In the Intents system, the client application requests a generic action, e.g. share, and specifies the data to pass to the selected service application. The user is given a list of applications which have registered that they can handle the requested intent. The user-selected application is created in a new context and passed the data sent from the client, the format of which is predefined for each specific intent type. We are hard at work designing an analogous system for the web: Web Intents. This web platform API will provide the same benefits of Android Intents, but better suited for web application. ... As with Android, Web Intents documents an initial set of intent actions (edit, view, share, etc.) that likely cover the majority of use cases on the web today; however, as the web grows and sites provide more functionality, new intent actions will be added by services that document these intents, some more popular than others. To foster development and use of intents, we plan to create a site to browse existing intents and add new intents.'"

Comments

Great

[Anonymous Coward]

More ways to track us! C'mon now, who's going to say how much this is for our own good. Let's hear it.

Re:Great

[X0563511]

Yea, in the same way that following a specific ABI in your C magically tracks your users...

Re:Great

[neokushan]

I don't see anything here that permits Google to track you any more than they already do.

Re:Great

[Anonymous Coward]

Exactly. My "Intents" are that Google pisses the fuck off.

Re:Great

[Desler]

The C ABI is not even remotely analogous to what Google is doing here.

Re:Great

[iluvcapra]

And if Google's C ABI required submitting all function arguments to Google...

Google works very hard to make submitting things to them very easy, to the point where you dont even realize any submission is happening, this just greases the rails a little more.

Re:Great

[Chrisq]

Exactly. My "Intents" are that Google pisses the fuck off.

Your intents are making you rather intense

Re:Great

[Anonymous Coward]

He seems to be incensed, as evidenced by his intense intents

Re:Great

[Anonymous Coward]

Being incensed over his intense intents has worked him into quite a lather. He should meditate to regain inner calm, and perhaps burn some incense.

Re:Great

[Anonymous Coward]

Didn't you anti-Google astroturfers get exposed a couple of months ago? Something to do with Facebook, right? You are all just getting boring now.

Re:Great

[tolkienfan]

Yes it is.

Re:Great

[Lunix Nutcase]

How so?

Let me know if I'm wrong...

[TubeSteak]

Google seems to be proposing a bit of javascript that anyone can add to their website,
which will pull my data from any other enabled website I've stored information on?

Why does this just seem like another entry point for abuse?

Re:Let me know if I'm wrong...

[McLoud]

Google seems to be proposing a bit of javascript that anyone can add to their website,
which will pull my data from any other enabled website I've stored information on?

Why does this just seem like another entry point for abuse?

Anything can be abused, give enough time and effort. It's just a matter of figuring if it is still worth giving how much useful it is still is. By the looks of the example it reminds me a lot of a ESB where You have services that do stuff registered in a common place, Google way seems like the REST counterpart of it.

Re:Let me know if I'm wrong...

[Pollardito]

AFAIK Android intents are push rather than pull. And that's a pretty big difference, since you have to either select the app/site you're pushing to at the time of the push or preset it beforehand (meaning you have control of who's receiving the data). This looks like it has a return path though, so it does seem like it might be risky.

Re:Let me know if I'm wrong...

[DragonWriter]

Google seems to be proposing a bit of javascript that anyone can add to their website,
which will pull my data from any other enabled website I've stored information on?

No, Google is proposing a set of web technologies (markup + JavaScript API) that will allow websites to advertise that they support certain actions, allow you to choose to install those websites as options to handle those actions, and then allow other websites to specify that they want one of those actions performed, at which point you will be presented by your browser with an opportunity to choose which of the sites you've installed as a handler for the action your browser should invoke to handle the action.

They are not proposing a mechanism that will allow websites to pull your data from other websites.

Re:Let me know if I'm wrong...

[RJFerret]

Sounds like ARexx brought to the Web (an expanded Rexx implementation on the Amiga from the '80s) but standardized.

The interaction between different applications was wonderful (Want to edit an image embedded in a document in your word processor? Update numbers in a spreadsheet or calculator? Send those updated numbers to a 3D model?) but required too much technical knowledge on the part of the user, due to lack of standard calls, or limited the end user functionality to developers who had worked together, limiting choices.

Re:Let me know if I'm wrong...

[DragonWriter]

Sounds like ARexx brought to the Web (an expanded Rexx implementation on the Amiga from the '80s) but standardized.

Its really not all that similar: ARexx was essentially a scripting language integrated into the Amiga platform and to which many Amiga apps provided an interface allowing automation.

Web Intents isn't a new language that sits external to web apps and allows you to automate them.

Discovery is done through one markup tag which advertises that service can handle a particular "intent" (an action), and consumption is done through either a form tag attribute in markup referencing the intent (not the specific service) or a dirt simple javascript API for specifying the intent and the content against which to apply it.

Re:Let me know if I'm wrong...

[Actually, I do RTFA]

No, Google is proposing a set of web technologies (markup + JavaScript API) that will allow websites to advertise that they support certain actions, allow you to choose to install those websites as options to handle those actions, and then allow other websites to specify that they want one of those actions performed, at which point you will be presented by your browser with an opportunity to choose which of the sites you've installed as a handler for the action your browser should invoke to handle the action.

So ActiveX then?

Re:Let me know if I'm wrong...

[DragonWriter]

So ActiveX then?

No, it has very little in common with ActiveX; the closest analogy that's been posted on the thread so far is UDDI, but its not very much like that, either.

Re:Let me know if I'm wrong...

[Anonymous Coward]

AFAIK Android intents are push rather than pull. And that's a pretty big difference, since you have to either select the app/site you're pushing to at the time of the push or preset it beforehand (meaning you have control of who's receiving the data). This looks like it has a return path though, so it does seem like it might be risky.

Would it be possible to PUSH to your Android? In other words, can your Android phone be made to look like a site/app to an attacking program?

API aka tie in

[Anonymous Coward]

Once you've written thousands of lines of code to make use of Google apps you will be just as stuffed as you were when you had all those lines of code which relied on Microsoft apps.

Re:API aka tie in

[bberens]

That's why you use industry standard libraries like jquery or yui which will hide all the nasty implementation details of various platforms from you and make it simple to develop. Only a few dozen people ever need to be bothered by the low level APIs.

Re:API aka tie in

[aztracker1]

ROFLMAO.... Funny, I've written a handful of jQuery extensions, just to work around certain issues, and knowing about the nasty implementation details was necessary. It's generally a good idea to understand what goes on underneath. I've had several times where understanding threading, and pointers has helped even when working on improving the performance of C# based applications. Developers who don't understand under the covers make stupid choices in ignorance. I don't like working close to the metal, I'm not that good with C, assembly, C++ etc... though having at least a general understanding helps a lot in developing applications in higher level languages.

The same is very true with JavaScript, and especially with platforms like NodeJS and MongoDB gaining in popularity (yeah, I'm a fan). Not understanding that string concatenation is far slower in most cases than array joins can be a huge difference (not as much in V8, as it does a better job in compilation, but still).

Re:API aka tie in

[oakgrove]

you will be just as stuffed as you were when you had all those lines of code which relied on Microsoft apps.

From TFA:

Mozilla is also actively exploring this problem space. In fact weâ(TM)re working closely with Mozilla engineers to unify our two proposals into one simple, useful API. Visit the examples page to try out the feature in any current browser. To explore using the API in your site, check out out the JavaScript shim, which provides an implementation of the API for browsers that have not implemented this feature.

So, not only are they working with Mozilla to standardize the API but they are creating a javascript shim for other browsers to play along too. Thanks for the daily dose of FUD though!

Re:API aka tie in

[Lunix Nutcase]

which will hide all the nasty implementation details of various platforms from you and make it simple to develop.

Yes, make it simple to develop shitty, inefficient apps because the "programmers" who bawww over actually having to learn how things work write absolutely abysmal code.

Re:API aka tie in

[Anonymous Coward]

Wow, what an elitist prick you are.

Re:API aka tie in

[Lunix Nutcase]

So wanting efficient programs and competent programmers writing them makes me elitist? Did I travel to the bizarro world?

Re:API aka tie in

[thePuck77]

Seriously. I am seeing so much of this lately...an attempt to put Google into the same box as Microsoft, Apple, and Oracle. The fact is that those companies represent a different era in business models and within the tech community. Google is as much a social reaction the state of affairs on the tech scene when they came into existence as they are a technological one. They saw the issues created by the companies before them and developed their approaches to those issues before they got big enough to apply to them. With one sentence, "don't be evil" they passed judgment on those who had come before them and pledged an idealogical stance (as opposed to a technological one). In addition to that, their chosen problem (to make the knowledge of world accessible and usable while solving the problem of online reputation and trust) is as much (or more) social and philosophical as technological.

This essential difference in stance and approach comes with its own problems. I am *not* saying that Google is some sort of corporate saint. What I am saying is that these issues that arise with other companies (such as the mentioned issues with Microsoft libraries, languages, frameworks, and even IDEs) just don't apply to the way Google has been going about things.

That said, I do think that a good programmer needs to understand and be able to cope with those "nasty implementation details". It's an easy way to write really bad code if you have no clue how the methods you're using work. However, on a day to day coding basis, libraries, frameworks, code generation, and autocompletion/intellisense help speed up development a great deal. As long as you understand what these shortcuts are doing, there is nothing wrong with abstracting away from and hiding the implementation methods, and you won't end up "stuffed" by using *anyone's* tools. There is no danger in learning C# and .NET and using Visual Studio to code apps using them. The danger is learning to use VS and thinking that means you really know C# (or C++ for that matter).

The one API

[Qatz]

One API to rule them all, One API to find them, One API to bring them all, And in the darkness bind them.

Re:The one API

[Anonymous Coward]

haha! you can't see my data! oh wait, krap!!

Re:The one API

[antdude]

So Google will be evil. :(

With Cray-4....

[Anonymous Coward]

Reading the description, you would need a supercomputer to manage this meta-meta-meta-language over meta-meta-meta-OS.
What's next? Fortune teller?

Simple

[Anonymous Coward]

When a giant advertising agency masquerading as a tech company announces it is breaking down barriers for the flow of information, what it really means is that it is breaking down barriers keeping your information from flowing to it.

We need the FOSS community taking charge, not Google. The amount of surreptitious data sharing and other scummy traitorware behavior on mobile phones is appalling.

We need a truly open mobile platform with truly open applications written to act in the best interests of their users, not for the bottom line of their corporate controllers.

Re:Simple

[royallthefourth]

We need a truly open mobile platform with truly open applications written to act in the best interests of their users, not for the bottom line of their corporate controllers.

Unfortunately, that's impossible in the current climate. No business will do this because there's no money in it. No group of programmers can just decide to do it either because they have day jobs to worry about and won't want to spend all their leisure time working just to churn out something that won't be up to the level Android is. What we would need to accomplish this (among other more important goals) is an economy that doesn't rely on the profit motive the function.

Re:Simple

[Anonymous Coward]

What we would need to accomplish this (among other more important goals) is an economy that doesn't rely on the profit motive the function.

That won't help. It's going against human nature. Take even the most simplistic forms of non-profitable user creation: game mods. 99% of the authors add in some crazy not-for-reuse or must-be-authorized-by-me unenforceable terms to derivative works (regardless of how their own work is illegal). And don't even get me started about the secretive culture in the mobile app realm.

Re:Simple

[Oligonicella]

Cool. Please describe one with enough detail that we can ascertain that it will work. Also, if it's an abstract concept with no analogue in the world, please provide a detailed migration plan that will avoid mass destruction as a probable side effect.

Re:Simple

[AvitarX]

I wonder if Mozilla is involved?

Mozilla is also actively exploring this problem space. In fact we’re working closely with Mozilla engineers to unify our two proposals into one simple, useful API.

Is that FOSS enough for you? because I would think that the Chrome team is part of the FOSS community, but you apparently do not.

Re:Simple

[slartibartfastatp]

Simple: it should rely on peer recognition. Plus, we give money to people with peer recognition.

Reinventing the Web Services Wheel?

[animeshpathak]

I might be missing something, but how is it significantly different from the work on languages such as WSDL used to describe Web Services? Is this just a JavaScript/REST version of the same?

Thanks,
-A

Re:Reinventing the Web Services Wheel?

[curunir]

From the sound of it, it decouples the service call from the service end point and allows the user to select which end point they'd like to use. Rather than making a call to a specific service provider, the page simply registers that it'd like some intent to be completed and then dispatches it. The user then gets to pick from the list of sites/apps that have registered their ability to handle that type of intent.

Re:Reinventing the Web Services Wheel?

[bberens]

One example I would use is mapping/directions. Let's say Bing Maps, Google Maps, and Mapquest have asked to be registered as mapping suppliers and you've allowed all three. Now on my website rather than linking to a particular mapping provider I call an api that tells your browser to provide a map to my local store using your preferred mapping provider. So you'll be prompted whether you'd like the map provided by Bing, Google, or Mapquest. Or if you have it configured it'll just automagically go to your preferred provider. That's only the simplest example and the sorts of things that currently exist on the phones, I'm sure someone more creative than me will come up with better ideas.

Re:Reinventing the Web Services Wheel?

[DragonWriter]

I might be missing something, but how is it significantly different from the work on languages such as WSDL [wikipedia.org] used to describe Web Services?

It specifies a JavaScript API and a basic end-user interaction model, which isn't part of the WS-* family of standards, and its about a billionth the weight of a web services standard because the actual markup doesn't encode very much at all.

I mean, look at http://webintents.org/

A complete definition of a service (a handler for an intent) is a single tag with three attributes, and other than the (pretty small) JavaScript API, that's all there is to it.

Re:Reinventing the Web Services Wheel?

[maxwell demon]

If done right, it would indeed be a very useful thing. However I'm not sure if Google really wants an interface which allows you to select whether you want the service "show the map of New York" requested from the web site to be served by Google Maps or Open Streetview ...

In any case, the user should be given the option to use a local program instead of a web app. For example, for "edit the image" I might want to use a locally installed Photoshop or Gimp instead of some web app which almost certainly is less powerful, and also likely less familiar (if I have an image editing software installed, most likely it's because I use it). But again, I don't think that's in Google's interest.

Re:Reinventing the Web Services Wheel?

[DragonWriter]

If done right, it would indeed be a very useful thing. However I'm not sure if Google really wants an interface which allows you to select whether you want the service "show the map of New York" requested from the web site to be served by Google Maps or Open Streetview ...

Its strange then that they have proposed pretty much exactly that, and delivered the code to implement it in existing browsers.

In any case, the user should be given the option to use a local program instead of a web app.

You can't really do that in a portable JavaScript shim of the type Google has delivered for the current demonstration, but obviously that's a fairly obvious thing to do in a native implementation within a browser (and most browsers already have a framework for defining local content handlers based on MIME types, though this would need to be extended to include actions as a distinguishing factor as well as content type to properly support intents.)

For example, for "edit the image" I might want to use a locally installed Photoshop or Gimp instead of some web app which almost certainly is less powerful, and also likely less familiar (if I have an image editing software installed, most likely it's because I use it). But again, I don't think that's in Google's interest.

Enabling you to more easily integrate your existing desktop apps with web apps (including, inter alia, Google's web apps) is clearly in Google's interest.

Re:Reinventing the Web Services Wheel?

[kbg]

So this is basically the same as UDDI for WSDL?

Re:Reinventing the Web Services Wheel?

[DragonWriter]

So this is basically the same as UDDI [wikipedia.org] for WSDL?

Its similar to UDDI or WS-Discovery in that it provides a service discovery mechanism.

Its dissimilar to them in that it also includes a JavaScript API for calling a service.

Its even more dissimilar in its lack of complexity.

Compare:
Web Intents
UDDI
WS-Discovery

Re:Reinventing the Web Services Wheel?

[Anonymous Coward]

The best example I can think of is adding an appointment to a calendar. Rather than offering iCal and vCalendar download options with some browser side hack to forward those to Google Calendar if that's what the user is using, the app would just dispatch an "Add Appointment" intent and iCal, Outlook, Sunbird and Google Calendar could be configured to accept that intent. The user could then choose one or more of those options to have the appointment added.

Re:Reinventing the Web Services Wheel?

[Unequivocal]

Thank you. Now I get it. Hopefully someone with mod points can use them on your post. +5 Informative!

Re:Reinventing the Web Services Wheel?

[Issarlk]

> Its strange then that they have proposed pretty much exactly that, and delivered the code to implement it in existing browsers.

Impossible! Everybody knows Google is eeeeeeeeeeeeeeevul.

Can anyone explain that in English?

[DavidinAla]

Maybe I don't have all of my brain cells firing this morning -- or maybe it's because I'm not a software developer -- but I don't have a clue what this API will actually allow people to do in real life if developers use it. Can someone explain in it in simple terms? Thanks.

Re:Can anyone explain that in English?

[pasv]

In plain English: google wants to control all your pipes and use information in said pipes to further their ad revenue.

Re:Can anyone explain that in English?

[Anonymous Coward]

If it works anything like Android, you would click a link to begin editing a photo inside the web browser, and a popup would appear allowing you to select from a list of popular photo-editing web services.

Re:Can anyone explain that in English?

[robmv]

Something like this, your web based applications will in some way register in your browser an API, another web application can call an that API, allowing a local web application be able to pass and receive data from another local web applications, from local I mean web applications that are running on your browser, without the server from application A know about server of application B and the data is trasferred to both applications locally. This solve the problem two problems, currently web applications must be coded to access specific thirdparty applications if they want to communicate, second, it hides the applications involved so application A do not know you are using applications B to edit a photo inside application A. The same way Android applications can call each other without knowing each other, only the Intents (or API). An "Inter process" communication between web pages in your browser

Re:Can anyone explain that in English?

[Anonymous Coward]

While that may be true, there could be potential here.

Intents are cool in that I can write an application for entering notes. I can then say if the camera intents are supported and the OCR intent are supported, take a picture, OCR, and give me back the text. If there's a camera, but no OCR intent, I can suggest the OCR program I used as a download. If they download one that they think is better, as long as it supports the same intent's it will just work. Obviously things like URL's/browsers and rssfeed/podcasts are much better supported then OCR. Still its a really interesting way to have loos dependancies.

Even within a program you could have a document editing piece. It can then use intents to store documents locally in a sqlite database. You could then write other backends that support the same intents to put it in googledocs, sftp to your server, use webdev etc It just standardizes how you do your API's a bit.

While I've thought it would be cool if the more traditional operating systems had a standardized similar way of doing things, in the websetting, its a bit different. Since we're talking web and not interaction with addon-ons, the person pre-defined which ones they are interested in. As such it seems like its quite a bit more ripe for abuse. Its google though, and I'm sure they've thought of that, so it might work.

Re:Can anyone explain that in English?

[MozeeToby]

Uh, no. Google wants to make it possible for you to make your website's abilities available to other websites (and in return, make it possible for your website to use other website's abilities). On android, I can write a shopping app that uses the built in camera app to allow the user to take a picture of the barcode, a free photo editing app to crop the picture down to just the code, and then the default web browser to actually show them information on the product. (Obviously, there are barcode scanners that don't require all the rigamarole, it's just an example).

Re:Can anyone explain that in English?

[lemonhead_bastard]

I see potential for things like a share intent that would then let me decide what service (Facebook, Twitter, LinkedIn, G+) that I want to use instead of having a thousand buttons on a webpage that do the same thing. Look at the mess that AddThis is, just a huge list of sites to post to. Intents would be a way to avoid all the junk you don't use. Intents for web could also be for retrieving content, or triggering video chats. Just a couple off the top of my head.

Re:Can anyone explain that in English?

[sorak]

Thank you, both for knowing what the hell TFA is talking about, and breaking it down in a way that the rest of us can understand. Why don't the people who make APIs hire people like you, to sell dimwits like me, on why libraries like this are useful?

Re:Can anyone explain that in English?

[bberens]

You know how when you click a mailto: link it brings up your system's default e-mail client? Well, with this API you could register several e-mail clients, including web based ones, and choose which one you wanted to use on a per-click basis.

Re:Can anyone explain that in English?

[robmv]

Exactly, eliminating the tracking those services do with those like, +1, tweet buttons forcing you to embed external (to your domain) scripts or add awful iframes

CORBA

[Anonymous Coward]

Being there, done it, already forgot it. And now Google invents it. LOL Guys, this kind of technology exists for more than 10 years. But go on Google, you have a record of "reinventing" the wheel.

Intents

[Nerdfest]

The intents model of Android is pretty cool and solves a lot of problems for Android, but I'm not sure how often it would apply on the web. It would be very useful for posting to Twitter, Facebook, etc from any site that uses intents I suppose. For me the lack of intents is one of the big problems with iOS. In early versions they built in FaceBook support. In v5 they built in Twitter support. Will they need to release a new version for Google+ support? Seems like a pretty serious design flaw (intentional or not). This may be another of Google's pushes they seem to be doing to make things more open.

Re:Intents

[bberens]

Sometimes I want my fat email client to get the duty of sending an e-mail when I click a mailto link. Other times I want to use gmail, other times hotmail. If I could register those different providers for that type of click then it'd make my life a little easier. When I go to [insert store here]'s website to find a local store it could show the directions using my pre-configured mapping solutions provider. If you prefer Bing over Google Maps you would get that automatically, or vice-versa. I don't envision it being "rock my world" type stuff, but it could improve the quality of your web browsing in ways that are not obvious to you at all.

Re:Intents

[brim4brim]

Well intents on the web will require some work and thought outside Android's intents for sure. For one thing, intents on Android allow you to select one intended target but on the web you could easily intend to sent it to two targets (faceboox and twitter) for example and that social intent is probably the best use of the intents system they are developing.

Then you have malicious use which on the web could be much easier achieved though presumably if Google was running the show, such websites would be removed from Google search results quite quickly.

Master API

[Anonymous Coward]

One API to rule them all, one API to find them...

Who owns the message bus

[Anonymous Coward]

I doubt it'll be p2p so... who is going to be and own the message bus? Google?

Re:Who owns the message bus

[maxwell demon]

Well, the most logical thing would be to have the browser handle it, and if there's a request type unknown to the browser, allow to search for it with a provider of your choice. That provider would be just a specialized search engine seeking for handlers instead of generic web pages, and it could be done by every search engine provider.

Of course it this matches what Google has in mind is another question.

Re:Who owns the message bus

[icebraining]

A better way in my opinion would be for the application launching the intent to "suggest" an adequate service, so if you didn't have any appropriate handler the browser could ask if you wanted to use that.

di3k

[Anonymous Coward]

a fact: FreeBSD simple solution wo8't be standing are 7000 users guest and never get of programming been the best, part of GNAA if head spinning (Click Here you can. When the project faces a set sanc7ions, and Sadness And it was If you have guys are usually users', BigAzz, Asshole about.' One another folder. 20 That comprise numbers continue The Cathedral taken over by BSDI the public eye: BSDI is also dead, dim. Due to the BUWLA, or BSD

If you have Android, choose "Share"

[brunes69]

Intents is one of the best and most powerful parts of the Android platform, and one that is often overlooked when comparing to iOS.

In pretty much any Android application under the sun, you can hit "Share" from a menu or button somewhere. When you do that, whatever data you have in that app posts a message to android saying "Hey, I want to share this (image/jpg or text/xml or application/octet-stream)... and any other application on the system that is registered to handle that intent's mime type will show up as something to share to.

This is what lets you share videos from anywhere on the phone not only to YouTube, but also to Picassa, DropBox, SMB, Email, or any other app that says they can handle videos or binary files.

It's a really powerful and flexable application cross-commnication system, that makes all kinds of otherwise disconnected third-party applications work together seemlessly for the user. For example, I can "Share" my PhotoStich images with my Dropbox, directly inside the application.... and none of the PhotoStitch or Dropbox developers had to talk to each other to make that happen.

Re:If you have Android, choose "Share"

[Anonymous Coward]

Have you actually programmed with intents? They are pure crap. A nice idea with a piss poor implementation. Mainly, you have no guarantee how the intent performs, or if intents actually do what they say they do. On my HTC Legend I rarely find an intent mime type which is NOT answered by the HTC mail app. What the fuck?

Also, please explain why if intents are so nice and great why all applications which care about quality implement their own twitter/facebook integration through static libraries rather than intents. So yes, it is a powerful decoupled mechanism, which sucks really bad, because you are down to a common denominator. And we all know how well that tends to go.

Re:If you have Android, choose "Share"

[Anonymous Coward]

UDDI - have a central service (your android) and a request for a resource (give me a map [here's a url for a map]), give me a function (a destination, an app) and invoke it.

Re:If you have Android, choose "Share"

[svick]

I have never heard about Intents until now and I too think it's a nice idea. You may be right that they are crap, but I don't agree with your reasoning. When you give control to another application, you can never know what is it going to do. How would you guarantee that any implementation of the "share" intent actually does that? Especially considering what "share" means cannot be encoded into some set of rules, that can be understood by a computer, without being way too restrictive.

Re:If you have Android, choose "Share"

[DragonWriter]

On my HTC Legend I rarely find an intent mime type which is NOT answered by the HTC mail app.

At least the proposed Web Intents use both content types and actions (edit, share, view, etc.); seems to me mail apps would be fairly unrestricted in the content-types they could handle, but very restricted in the actions that they can handle for most content types.

more crap to break

[Anonymous Coward]

All this sounds like is just one more level of crap to break. Universal adoption of standard api calls would be wonderful, but adding a man in the middle just sounds like trouble.

Couldn't resist

[shoehornjob]

And one Master API to bind them all. Ok so it's not really funny but I'm in a goofy mood today.

I propose a 4 letter type and creator tag

[JasperCraft]

That way the client can open up the app that created it or something else that can

Wait a minute...

[biodata]

In the mid 90s when the internet was competing against the paywalled gardens of Compuserve, AOL and the like, I distinctly remember sensible business people asking the quite reasonable question "Why will the internet ever amount to anything other than a university system for public sector communications? If noone is willing to pay for anything they see online, then noone makes any money, and nothing ever gets built.". The answer, as far as I remember was always that advertising would pay for the internet. That our eyeballs are valuable enough for people to put up the money to put up the infrastructure to engage our eyeballs on behalf of their advertisers. Nothing has changed. The advertising company is putting up the money for the infrastructure and giving it away for the price of eyeballs, that is the economic bargain we all entered into.

Don't drop the SOAP

[Anonymous Coward]

One format of calling methods, describing data formats, and doing things out of band. Sounds a lot like SOAP if it scrubbed off XML.

Wrap around another wrapper

[layer3switch]

great.... this has potential of bloat written all over.

Re:Wrap around another wrapper

[DragonWriter]

There is no "wrapper" involved.

A little suprised...

[wstrucke]

this hasn't been patented already.

Re:A little suprised...

[Co0Ps]

Why? This is real innovation. Real innovation is not connected to the "patent system" in any way even if lawyers, patent troll companies and others that profit from patents like to paint a picture of a world that works like that.

Re:A little suprised...

[wstrucke]

Because the trend these days is to patent any idea, especially if it's somewhat vague, like "An API for everything". I'm not implying it isn't novel, just that it seems like a target for abuse.

Master API?

[Mathinker]

A "Master API"? What device does that interface to, a universal controller?

more reading

[Anonymous Coward]

linked from TFA: Mozilla's take
linked from Mozilla's take: blog post by someone at Google who talked about it last year