Google Earth API Will Be Retired On December 12, 2015 75
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.
Ouchy (Score:4, Insightful)
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 :(
Fate of other Google APIs (Score:1)
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?
Re: (Score:3)
Yes.
http://www.wordstream.com/arti... [wordstream.com]
Re: (Score:2)
More useful: Linking to an actual article. [wordstream.com]
Re:Alternative? (Score:4, Informative)
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 [mozilla.org].
Re: (Score:1)
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.
Asm.js is such idiocy. (Score:4, Insightful)
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!
Re: (Score:1)
Oh, you have *such* a limited knowledge of programming languages. In the computing world, eons ago (1959), a few very smart people (Grace Hopper, William Selden, Gertrude Tierney, Howard Bromberg, Howard Discount, Vernon Reeves, Jean E. Sammet) came up with a quickie language that would run on the new computer hardware that was coming out (still tubes mind you, but the transistor came along in 1957). It was born and fledged in less than 6 weeks. It was meant to last 6 months till something better came al
Re: (Score:1)
Yes if you find yourself facing COBOL what you need is a cross and some garlic. Its the MONSTER that just will not die.
Re: (Score:2, Flamebait)
Summary:
1) I hate Javascript.
2) asm.js is bad because I say so.
3) I hate Mozilla.
Number of factual statements about asm.js or its problems: Zero.
Re: (Score:2)
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.
Re: (Score:1)
Open them in Adobe Reader (Score:2)
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.
Re: (Score:2)
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 webs
Re:Alternative? (Score:5, Interesting)
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.
Google can change behaviors behind Mozilla's back (Score:4, Informative)
Re:Alternative? (Score:4, Informative)
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.
Re: (Score:3)
Re: (Score:2)
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.
Chrome ain't done till Firefox don't run (Score:2)
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."
Re: (Score:2)
Re: (Score:2)
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 ima
Re: (Score:1)
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 getti
Re: (Score:1)
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 [mozilla.org].
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.
Re: (Score:1)
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.
Re: (Score:2)
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 coul
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:3)
Nobody's banning (all) plugins AFAICT. Google is discontinuing support for a specific plugin API. Not the same thing at all.
Re: (Score:2)
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.
Re:I want plugins! (Score:4, Informative)
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.
Re: (Score:1)
I'm not complaining (Score:5, Funny)
Re: (Score:2)
does Google have a single source for announcements like this?
I believe developers who have registered to use a particular API are notified by e-mail of changes to that API.
Re: (Score:2)
Re: (Score:2)
That's fine for APIs that require registration. But I use the Calendar API. It doesn't require registration, and like many people I was caught out on the hop on November 17th when the v2 API was shut down. Like I said I'm not complaining. The v3 API is superior, but I would like to know if there is simple notification system available.
Well, in that case I think the best answer is to pay attention. I mean, the v2 API deprecation was announced at least three years prior to the shutdown. I don't know exactly when, but there are mailing list posts from 2011 telling people that v1 and v2 were deprecated and v3 should be used.
Re: (Score:2)
And those of use who just used SW using the API are just SOL. One day I came into work and found that my calendar integration between Thunderbird (Lightening) and Google Calendar was no longer working. And I couldn't upgrade the Google Calendar provider addon because the new version required a new version of Thunderbird, which I cannot install because it doesn't work on RHEL5 (they are slowly upgrading to RHEL6).
I was able to get it to "work" by switching to ICS, but that is read-only (apparently). So at
Re: (Score:2)
you are funny and typical of slashdot crowd, whining when a large company eliminates little-used things. Other than niche geek crowd, no one used Google Reader, average person has never heard of it
Re: (Score:2)
If this is what your company thinks of its users, I hope I never use any of your products.
Where I work, we have fairly strict rules about documenting altered or deprecated features well ahead of time, even in the products we give away gratis.
OTOH, we actually make our money from selling and supporting our software, whereas for Google it's merely a loss leader.
Re: (Score:2)
Apparently you only saw "Google", went into frothing mode, and so missed this:
Where I work, we have fairly strict rules about documenting altered or deprecated features well ahead of time, even in the products we give away gratis.
In case you'd not heard, "gratis" means "free as in beer".
Care to try again?
Re: (Score:2)
What foolish world do you live in where a global company with ad-based revenue has to support a niche project that flopped without large user base? They ARE thinking of the majority of users, their survival depends on it. Of course they cull the flops as they well should. There is no question of right or wrong, ethics or any other bullshit you seem to imply for their gratis services.
Your happy flying unicorn world only exists between your ears, no one has to abide by it
Re: (Score:2)
I'm sorry, am I a Google fanboi or a Google hater today? I keep getting categorised as one and then the other so often that I've grown confused.
Or is it that I'm an idiot because I think users should be treated with a bit of respect?
I can't tell any more.
I do know that where I work--as I said before--we don't consider how many or even IF there are any users of a particular feature or API before we drop it. We have a deprecation process for such things, and AFAICT we stick to it.
Re: (Score:2)
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.
Glad I Didn't Build an Application Around That (Score:4, Interesting)
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.
Re: (Score:3)
Is there a "MyTracks" equivalent that just works offline on the phone?, I had a buddy install it on his and then it asked to be tied to one of two proposed google e-mail addresses. While not highly tech savvy he just refused the "deal", because uploading your location every x minutes or seconds smells of science-fiction dystopia. An offline KML or similar file on the phone you can load on the computer via USB and then into Google Earth, that would have been more acceptable.
Re: (Score:2)
I think there's
Re: (Score:2)
I've hiked in the backcountry for a week in Airplane mode with MyTracks recording just fine the whole way. MyTracks can also save your KML or other formats to your SD card for easy access last I checked.
Re: (Score:2)
I'm not sure I understood what you want to do.
Do you just want to display your 3D path?
If so, gnuplot or matplotlib would do.
If you want more information and more interactivity, just use SketchUp.
You can write a small Ruby script to display one path for each skydiver, geolocate the model and display a map on the ground.
Re: (Score:2)
Re: (Score:2)
If you have an array of (t,x,y,z) points, it shouldn't be hard to do.
It sounds like you clearly know what you want, so you could either code it or make someone code it for you.
Python+maplotlib or Sketchup+Ruby would do just fine.
Re: (Score:2)
Only in Beta anyway (Score:2)
good (Score:1)