Slashdot Mirror
Google Earth API Will Be Retired On December 12, 2015
An anonymous reader writes Google [on Friday] announced it plans to retire the Google Earth API on December 12, 2015. The reason is simple: Both Chrome and Firefox are removing support for Netscape Plugin Application Programming Interface (NPAPI) plugins due to security reasons, so the API's death was inevitable. The timing makes sense. Last month, Google updated its plan for killing off NPAPI support in Chrome, saying that it would block all plugins by default in January and drop support completely in September. The company also revealed that the Google Earth plugin had dropped in usage from 9.1 percent of Chrome users in October 2013 to 0.1 percent in October 2014. Add dwindling cross-platform support (particularly on mobile devices), and we're frankly surprised the announcement didn't come sooner.
The reason why so relatively few dare putting their long-term stuff on Google App Engine: they suddenly feel the need for a spring cleanup and, boom, your investment goes south.
Yup, I went through the calendar api death amongst other things :(
Not that I'm complaining, but you really do need to pay attention to Google's plans if you have any applications that make use of their APIs. They do love to cast things adrift on a pretty regular basis. Maybe I don't do enough development to pay the proper attention, but does Google have a single source for announcements like this? Perhaps an RSS feed would work, then I could use Google Reader to keep an eye on things. Oh, right.
My UID is prime!
So what is NPAPI being replaced with across the browsers, please?
In Chrome, PPAPI. New versions of Adobe Flash Player already use it. In Firefox, asm.js. Adobe Flash Player is the only NPAPI plug-in that Firefox shall allow.
How does asm.js interface with the Java applet platform and Adobe's PDF reader?
And please don't tell me that I don't "need" Java - it's way nicer for actually providing a precise, fast, rich client experience in the browser, and Adobe's PDF reader actually renders every document properly, unlike native browser PDF readers.
Nobody's banning (all) plugins AFAICT. Google is discontinuing support for a specific plugin API. Not the same thing at all.
Il n'y a pas de Planet B.
This is definitely not the first time an Google API bites the bullet --- what I am wondering is, what about the fate of other google APIs?
Will they go "poof!" as well?
Asm.js just about sums up everything that's wrong with Mozilla today (and that's a whole helluva lot!).
Asm.js is just JavaScript. That's all it is. It's JavaScript. Mind you, it's a subset of JavaScript that's awful for humans to work with, but it's still just a subset of JavaScript.
The first problem is, obviously, that asm.js is JavaScript. JavaScript is, by far, the worst mainstream programming language ever to have been created. It's riddled with unjustifiable flaws, from its very foundation to its very peak. I don't give a fuck if Brendan Eich only had a week to get it working, back in 1995. That was almost two decades ago. That's lots of time for these goddamn stupid problems to have been fixed many times over. Mozilla needs to get over their raging hardon for JavaScript. It's a bad language, and it needs to go.
The second problem is, obviously, that asm.js not a proper bytecode-based runtime like Java, .NET, or PNaCl, yet it's intended to be used as if it were a proper bytecode-based runtime. When you try to use some turds as a pair of boots in a storm, your feet will get soaked and smelly. It's the same principle when you try to use JavaScript as a replacement for a proper bytecode-based runtime.
The third problem is, obviously, that Mozilla keeps on pushing this idiocy, even when it's clear that asm.js is a fucking stupid idea and the wrong way of doing things. But that's just how Mozilla works these days. This we're-doing-the-wrong-thing-and-it's-obvious-but-let's-keep-on-doing-it-even-when-our-few-remaining-users-beg-us-not-do philosophy of theirs has extended to all of their projects, and it shows.
Jesus Christ, Mozilla, get rid of asm.js and use PNaCl. PNaCl is sensible, even if it did come from Google.
Asm.js needs to go! It's shit!
I never installed Java in the first place on this computer. It's just too much hassle. Those very few sites that have Java plug-ins... I can live without.
You are in a maze of twisty little passages, all alike.
Don't worry. Only the crusty NPAPI support is removed. PPAPI is the modern interface for plugins.
Besides, the idea you described makes more sense to be implemented in form of an extension instead of a plugin.
One of the things I do with Google Earth is install a GPS tracker on my cell phone and take it on a skydive. I use MyTracks to log my coordinates every second and use a little application I wrote to turn the MyTracks data into a KML file, detect where I deployed my canopy and drop a push-pin there and plot the jump on Google Earth so you can see the jump in 3D. MyTracks actually has an "Export to KML" option, but it doesn't handle altitude very well and just clamps your entire track to the ground. Apparently the developers didn't consider the "I'm 2.5 miles above the surface of the planet" use-case when they wrote the thing heh.
The cell phone isn't a great GPS tracker to use for this -- the GPS hardware in the Samsung Galaxy S5 I'm using now is actually almost usable. The S3 used to regularly lose 2/3rds of the points on my jump. There are custom skydiver GPS units available that have much higher accuracy, and they're used regularly in wingsuit competitions and stuff like that. It'd be really neat to plot an entire load of skydivers together on Google Earth and do a real-time replay of each one's position along their track during the jump. I could pull this off using the socket server method of putting KML into Google Earth and updating a new point for each wingsuit's location every second. It wouldn't even really be all that much work, but I don't really like how I'd have to do the design, and that's kept me from it.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
It's isn't being replaced with a cross-browser API. Google wants you locked into their proprietary browser plugin API. They dislike that NPAPI is cross-browser.
Java - it's way nicer for actually providing a precise, fast, rich client experience in the browser,
The only thing the Java applet platform is "nicer" at is providing a huge security hole in your system to be exploited. Java applets are ugly, slow and horrendous to use.
Mozilla's refusal to implement PPAPI and Adobe's refusal to fix bugs in the NPAPI version of flash is going to cause a lot of problems in the future. For example, right now, the NPAPI version of Flash can't handle HiDPI properly (retina display and Windows at non-96dpi). Websites that use Flash for video or text display are unusable if you have a 192-dpi screen already, and it's only going to get worse as HiDPI both becomes more common and people start using even higher DPI devices.
Meanwhile, the same websites display just fine in both Chrome (PPAPI Flash) and IE (ActiveX Flash).
Morphing Software
PPAPI is the modern interface for plugins.
By "modern" you mean Google Chrome only, right? Vendor lock-in does seem to be what "modern" means these days mostly.
I actually think Javascript is a prime plugin platform, its an automatic memory management language that rules out memory handling errors such as buffer overruns, thus safely eliminating a class of serious programming errors. The use cases where NPAPI were once used can be fulfilled by Javascript in nearly all cases, and the built in Video and audio capabilities in current browsers, and the proposals for 3D Javascript APIs that can be used safely from Javascript. It is possible that Javascript programs could be accelerated safely with a Just In Time Compiler and caching native object code, which can be done while maintaining the same security features of Javascript interpreter, native machine code would be heavily managed, using the Javascript runtime for memory management and so on, giving it the same safety features as interpreted Javascript. The JIT and caching feature should be able to be disabled by the user forcing the interpreter to be used but if done right JIT should be as safe as the interpreter.
NPAPI needed to go. It encouraged developers to write code in a non portable way and to distribute non machine portable code that could only run on a few platforms. RIP.
So no harm done.
So what is NPAPI being replaced with across the browsers, please?
In Chrome, PPAPI. New versions of Adobe Flash Player already use it. In Firefox, asm.js. Adobe Flash Player is the only NPAPI plug-in that Firefox shall allow.
PepperFlash is substantially slower than NPAPI flash, and I disable it every time Chrome re-enables it. Get the performance of PPAPI to within 5% or even 10% of NPAPI, and I'll consider using PPAPI. Until then, I don't need Google to push my computing experience back the equivalent of 4 years of hardware.
Don't blame Mozilla for this. Google is intentionally keeping PPAPI exclusive to Chrome.
The API is not documented or standardized. A lot of parts of it are explicitly secret (only Google and select partners like Adobe know about them). The only standard is "it should do whatever it does in Chrome," and Google designs it around Chrome without any concern for accommodating other browsers. So even if Mozilla poured energy into reverse engineering it and implementing what would necessarily be a slower, less complete shadow of the Chrome version, Google could (and would) still pull the rug out from under you by changing the API next month. It's just not an option.
Google is being incredibly petty and anti-cooperative with this stuff and people act like they're Goddamn pioneers. It's the same shit you see with Android/Google Play, or with Mir in Ubuntu--they call it "open" but it's not open enough for anyone else to actually use.
I think what you write is weird and it had me check the date. Javascript is JIT'ed already and the browser will choose between an interpreter, JIT or more advanced JIT depending on the size of code to run. Then you're at the mercy of the programmer for it's him/her who writes it and gives you efficient code, inefficent code or code that does too much. Perhaps it runs fine on programmer's i7 laptop when the test browser is not running something else, so let's push it on the unsuspecting world.
It's so secret that they have their own Google Code page for it over at https://code.google.com/p/ppap... with full source available for download including SDKs for plugin developers.
Adobe's PDF reader actually renders every document properly, unlike native browser PDF readers.
I can't speak to Java applets (what still uses those?) But you can still download PDFs and open them in Adobe Reader. This lets you take advantage of the memory barrier that the operating system already enforces between firefox.exe and acrord32.exe.
First, Adobe can choose to make Adobe Flash Player for PPAPI available only through Google. Second, PPAPI is not frozen. Google can change behaviors behind Mozilla's back.
Because then Mozilla will go through all that effort to implement PPAPI but then Google will change PPAPI on a whim and it will break all the plugins on Firefox and people will ignorantly blame Mozilla, and then Mozilla will have to put all that effort into updating to the latest random revision of PPAPI only to rinse and repeat.
Uh, that repo's been dead for over 4 years. Says so right in the blurb: "Currently the canonical version of the PPAPI code has moved to the Chromium subversion repo". It's heavily integrated into Chrome now, and Google control all changes, so it's hardly ideal for a cross-browser plug-in API.
Still, better to have bad code run in a sandbox than to have access to C level capabilities where it can do buffer overruns. Firefox drops the ball on not allowing people to enable some things only when necessary. Its sort of sad that IE's security zones are actually better than anything Firefox has. The idea behind security zones is you can put a site into a security zone, and then the settings of that security zone are applied whenever the site is loaded. You can disable scripts, cookies, plugins and such in a security zone. The important thing is the zones all work in the same browser process, you dont need to use seperate instances of the browser, when you go to a site the security zone settings for the site are automatically applied. There is a default security zone whose settings apply to all sites no added explicitely to another zone. So your default zone can disallow cookies, scripts, flash plugins and so on, and then when you come to a site that you trust and needs these things, you can then put that site into a security zone that enables these features.
I know firefox has NoScript, but this falls short because you want one solution that can do it all, because you really want to stop cookies and plugins too, so its a good idea to be able to use the same zones feature to control all of this.
I blame Mozilla because they could at least offer subpar work-arounds (blurry 2x scaling, half-assed PPAPI implementation, etc) for the NPAPI flash, but they choose not to. As much as I would like Flash to go away and be replaced with HTML5 video and Javascript, the real world situation is that big sites like CNN and Google Finance use Flash for video and charts that I simply can't access on my laptop now, because everything is too tiny to use. This laptop is only 2880x1620 and set to 200% scaling, but imagine how much worse things will look once laptops start having 4K displays and beyond. Meanwhile, right now, Chrome and IE both display all Flash content the correct size, so what am I to do? Obviously, on this laptop, I have to just not use Firefox. This sucks, because I otherwise think Firefox is the by far the best browser choice out there for a large number of other reasons.
Morphing Software
Yes it sais so and links straight to the ppapi code used in chrome which is fully open source: https://src.chromium.org/viewv... . Hell even the chrome repository for ppapi is full of examle code if you want to write your own plugins.
So PPAPI is essentially a Chrome-internal API, much like XPCOM is for Mozilla? (Complete with random backwards-incompatible changes, and needing to recompile for every version of Firefox ever because they do a check on the binary and immediately refusing to work if the version number doesn't match.)
NPAPI was useful because it was written as a spec and got to a point where basically nobody could change it. It was also useful (unlike e.g. asm.js) because it could talk to the host OS and do things like getting to the graphics hardware with fewer levels of indirection. It got crashier as the browsers started changing it anyway (to shim in support for running the plugins out of process).
Browsers these days really, really want to be the platform, except without providing the stability a platform is supposed to provide, and more CADT-style things.
Then where's the frozen version of the spec that other browser developers can implement to interoperate? Otherwise it's "Chrome ain't done till Firefox don't run."
1997 called - they want their insults back!
Christmas Card Messages 2014 Christmas Wishes Messages 2014 Christmas Greeting Card Messages 2014 Christmas Card Messages 2014 Christmas Messages 2014