Monthly Archives: April 2010

No more jsonp for Google geocoding webservice?

I needed to do some reverse geocoding in a javascript webapp. The Google Maps API worked flawlessly, but it seemed overkill to load all that javascript just to do one lousy reverse geocoding lookup (esp. on a mobile device, my target platform).  I searched some more and found the Google geocoding webservice, which is invoked with a simple HTTP GET request and returns the response in JSON. Version 2 of this service works great, as you can specify a callback-function to do jsonp (a simple method to allow for cross domain ajax requests),

This example request for v2, http://maps.google.com/maps/geo?q=51,4&sensor=false&output=json&callback=parseme, results in a response containing a call to your own “parseme”-function, with the json-object as the payload;

parseme && parseme( {
"name": "51,4",
"Status": {
"code": 200,
"request": "geocode"
},
"Placemark": [ {
"id": "p1",
"address": "Brukkelen 191, 9200 Dendermonde, Belgium",
...
]})

But a month ago Google announced a new version of their geocoding webservice and the documentation for V2 mentioned that it was deprecated in favor of the Geocoding V3 Web Service. so I switched to the new API, only to discover that callbacks aren’t supported any more.

An example request for v3 http://maps.google.com/maps/api/geocode/json?latlng=51,4&sensor=false&callback=parseme results in nothing but the javascript-object:

{
"status": "OK",
"results": [ {
"types": [ "street_address" ],
"formatted_address": "Brukkelen 191, 9200 Dendermonde, Belgium",
...
]})

And that, my dear fellow travellers, sucks big time. JSON without the P means we’re back to useless proxy-scripts on our servers. So until Google lets Jason pee (sorry folks, I just had to write this) in the V3 geocoding webservice, I’ll continue using the deprecated V2 with sweet -but undocumented- callback!

As found on the web (April 7th)

generic (feed #49)
generic (feed #49)
frank posted Flash Demos.
generic (feed #50)
generic (feed #49)
generic (feed #49)
facebook (feed #40)
frank Frank zag 4 facebook-vriendjes waarvan 3 oud-collega’s op een project komen pitchen, leuk! :-)..
generic (feed #50)
generic (feed #49)
generic (feed #49)
generic (feed #50)
generic (feed #49)
generic (feed #49)
generic (feed #50)
generic (feed #50)
generic (feed #50)
generic (feed #50)
generic (feed #50)
generic (feed #49)
generic (feed #49)
facebook (feed #40)
frank Frank kan geen group & friend-requests meer aanvaarden, nog mensen?.
blog (feed #46)
frank published WordPress galore.
generic (feed #49)
frank posted Hell.
youtube (feed #51)
frank liked 3 videos.
facebook (feed #40)
frank Frank moet echt niet weten waar ge zijt, maar wat ge doet of denkt en klikt dan ook op *hide foursquare*..

WordPress galore: plugin bugs, android app, json-api & wp 3.0

Some random WordPress-related thingies I’ve been looking into;

  • I bumped into a weird bug in css-js-booster which caused error-messages like
    <!-- Booster had a problems finding wp-content/
    plugins/css-js-booster/../../../../../../
    3f540bbd99f8ebecb73880a685db76ae_plain.css -->
    

    to appear in the html-source, although all CSS seemed to be processed. The problem was caused by PHP’s safe_mode and got fixed in 0.2.2, thanks der Schepp!

  • A few days ago my entire WordPress-blog returned empty pages, the admin-section included. Turns out that this “white screen of death” is a known issue with the WP super-cache plugin when combined with PHP APC (2 of the main components of my “Speed up WordPress“-post). As this only occurs rarely, I’ll stick to restarting Apache for now (I don’t want to switch back to eAccelerator) but I hope the APC and WP Super-Cache teams will look into this further.
  • After ditching Google Analytics, I looked into how WordPress stats are collected. Indeed, the script is sourced at the end of the HTML, thus slowing down the rendering of the page.  Let’s hope someone at Auttomatic reads Steve Soulders’ very interesting blogposts on “Performance of 3rd Party Content” and decides it indeed is time follow Google Analytics’ example and switch to asynchronous loading of the WordPress stats Javascript.
  • I installed the WordPress Android application and played around with it a bit. I don’t think I’ll be posting with it any time soon; writing on a small touch-device is a hassle, there’s no such thing as a rich HTML editor and  updating pages and especially posts or comments is very slow (because of the incredible overhead and complexity of the xml-rpc API?). Still, nice to see the WordPress-icon on my HTC Hero ;-)
  • Thinking about that clumsy WordPress xml-rpc API (which I experimented with approx. 1 year ago), I started looking for a plugin that provides a rest/json api. JSON API does just that and it has great potential, but it might not be suited for public-facing WordPress installations just yet, as it allows unauthenticated users to create new posts. So you might want to wait for authentication to be added to JSON API before installing it?
  • And I just read that the first beta of WordPress 3.0 was released; wordpress and wordpress.MU get merged, menu management and a new theme are but a few of the new features. Wouldn’t is be great if functionality/ ideas from wp-super-cache, css-js-booster and json-api would be added as well?