Category Archives: JavaScript

Cross-origin data access from JavaScript

WattDepot features a RESTful API that emits XML, and supports the Google Visualization API using the Google-provided Java library. There is a Java client library that makes it easy to write WattDepot clients in Java, and Google provides a library for JavaScript clients using the Google Visualization API. A several Java clients have been written and several JavaScript clients have been written.

Yichi Xu is working on a GeoMap visualization for WattDepot, and it needs to use the REST API rather than the Visualization API. This means he had to query the REST API directly, and parse the resulting XML. He quickly ran into the same-origin policy in JavaScript. In short, scripts running from a particular domain can generally only access resources from that same domain. This makes sense, because you don’t want any random web page you browse to have access to all your email just because you have a Gmail window up. However, from a developer’s perspective, this is a big when you want to use an HTTP API. Yichi’s gadget is loaded either locally or from Google’s servers, so when it tries to perform an HTTP GET to the WattDepot servers, it fails due to the same-origin policy.

There are a few workarounds for this problem, and Nelson Minar provides a good introduction. You can use proxies, but that’s gross. The most common solution makes use of a loophole in the same-origin policy: you can load JavaScript code from anywhere (just not data). So if you wrap your data so that it looks like code, then you can violate the same-origin policy. If you are providing the data in the JSON format, once wrapped it becomes JSONP.

Right now, WattDepot doesn’t support JSON representations (though it may in the future), so the JSONP trick is not available to us. Luckily, Yichi came across this draft from W3C on Cross-Origin Resource Sharing. CORS allows servers to emit HTTP headers that indicate how browsers should restrict access to the resource. The header can open things up so anyone can use the resource, or only certain other domains. However, this requires browsers to act on the header, luckily Firefox 3.5 and the latest Safari both implement this (the Firefox page has an excellent discussion of CORS). For now, supporting Firefox 3.5 and Safari is acceptable, so WattDepot just emits “Access-Control-Allow-Origin: *” for all requests. In the future this will be cleaned up to only emit this for public sources, and also provide JSON and JSONP representations for easier use in JavaScript.

JavaScript Charting Packages

I was looking at Google Finance and marveling at their nice interactive chart. Such a chart would be very sweet for Hackystat or a Saunders kiosk. I thought “surely someone has written a open source JavaScript charting package”, and began Googling.

Later I realized that Google Finance is using Flash for their chart (boo!) so the playing field is not quite level.

Ffor interactivity I could only find one package: Emprise JavaScript Charts. It looks pretty sweet, but it is commercial so it’s not clear how useful it would be for Hackystat.

Other JavaScript charting options (none allowing scrolling and dragging as far as I can tell) are: PlotKit, Plotr, and WebFX Chart Widget.

One problem with making charts via JavaScript is the lack of a good cross-platform drawing system. The implementation page from WebFX Chart has a pretty good summary of the situation. It appears there is no perfect solution, but Canvas seems to be the best cross-platform option.

There appears to be a lot of activity in this area (many of the packages listed are pre-1.0) so perhaps this is a case where procrastination will pay off.

Sadly, I cannot seem to find a link to the paper I remember reading that showed that procrastination can be effective when purchasing a compute cluster to work on a particular project. A cookie for any CSDLer that can dig it up! 🙂