Remote APIs, Hashing, Encoding, Dates
Kris Kowal
feature progress in Chiron and I wanted to get this email list primed
for future developer discussion.
Recently added:
These are all of our remote data API's. They all support the same
basic interface now: there's a "request*" function that accepts a URL
or options including a URL, and a callback (functor) that gets sent
the result when they're ready and okay. The callback is optional if
synchronous requests are possible.
http.js: http.request, http.requestText, http.requestXml, http.requestDocument
json.js: http.requestJson
jsonp.js: http.requestJsonp
xmlrpc.js: http.requestXmlrpc
http.js has been around a while; nothing new there. It does URL
parsing (a la Steve's regular expressions), and XML HTTP Requests.
It's been tested in all browsers and since it's at the core of
modules.js, it's pretty old, dry and solid.
json.js has also been around for a month or so, but I just added the
requestJson convenience wrapper. JSON requests are merely XHR
requests that evaluate the returned text as JavaScript and return the
result. To provide some ammount of protection from progammer
mistakes, the JSON is evaluated with module.js's evalGlobalWith
function, which IMO is totally wicked.
jsonp.js is new this weekend and permits JSON requests to be called
and gets around the same-origin security policy. It works by adding
and removing <script> blocks that refer to JSON-P data-sources. The
trick with JSON-P that makes it different from JSON is that it
requires a "callback" parameter in the URL string, which the host puts
in front of the JSON. It's called "Padding", thus the P, and it
causes the remote script to call a function that the requester has
dropped in global scope for their convenience. As usual, I've done
what I can to prevent accidental global variable collisions by
linearizing JSONP requests and cancelling them after a timeout (which
can be overridden). It works pretty darned well so far. The demo
works for Google's JSON-P API anyway.
xmlrpc.js is partially complete. I translated some code I found in a
dark corner of the web (http://sourceforge.net/projects/xmlrpc) for
generating request messages from JavaScript objects, even taking the
liberty to make it use any user-defined json or xmlrpc method
overrides to generate XML serializations of JavaScript object
hierarchies for remote method calls. I also, as usual, opted to use
Python's idiom for base type augmentation. That of course is to _not_
augment base types, but rather provide module-scope functions that "do
the right thing" for objects that were authored before the given API
layer and permit objects authored later to define their own overrides
as methods. This pattern is ubiquitous in base.js. So, XMLRPC is
nearly complete except that I haven't written or found any code for
traversing the response XML and generating JavaScript objects from it.
All in due time.
Steve wrote a Date/Time formatting library which we've integrated.
It's already used to format UTC ISO dates for both JSON and XMLRPC.
I also found some free code for encoding and hashing that I've added
to the library since they might come in handy down the line. We now
have all these libraries:
utf8.js
base64.js
md5.js
sha.js
sha256.js
crc32.js
As usual, I'm trying to keep the API's orthogonal. They all implement
encode (and decode if appropriate). Other names might be more
appropriate, but nominally you can swap hashing modules with very
little change in client code.
I also posted select.js, which is Jack Slocum's implementation of CSS
selectors and XPATH which he donated to Prototype and jQuery under the
MIT license. I take that to mean that it's MIT licensed period, but I
haven't heard back on my inquiry on the topic; if anyone is close
enough to him to check his pulse, please let me know.
From a project management perspective, the goal is to be feature
complete for release 0.1 by the end of this month, our feature freeze
date, then spend December fixing bugs, fleshing documentation, and
deploying a "marketing" page much like modulesjs.com. You can check
out the roadmap if you're interested:
https://cixar.com/tracs/javascript/roadmap
On a side note, modules.js works great in Safari, Firefox, and
Explorer, but not much else of the library does at the moment.
Performance hindrances in IE 6 mean two things: in the short term, all
the modules that depend on base.js perform soo poorly in IE, that the
cost of its elegance is unusability, relegating those modules to the
realm of academic exercise until Internet Explorer is assaulted by
screaming monkeys. This also means that I need to scale back base.js,
forcing less commonly used functionality into other modules, and
actually get a nightly build system up so we can see how well it
performs regularly when it's accreted, shrunk, minified, and
compressed. The way I see it, Moore's law will charge forward, I'll
float backward, and maybe we'll meet about the time that everyone in
the world realizes that they really do need a free, "batteries
included" JavaScript library.
Kris.
So now you should go back to the top and actually read them long
paragraphs. Or not.