There are a few editions of this library floating round. This copy is my own source from original materials. There is an edition I left at an employer, which included some work done inside company time, to improve integration with a form renderer I wrote as part of my dayjob. Anyone has the test scripts that this was distributed with, please mail them to me (I lost alot of files in a hard disk failure).

Using jQuery may be more consistent these days.


  • To harmonise between different web-browsers partial support;
  • To be usable inline of existing systems so need to support COOKIEs etc;
  • To provide a simple API;
  • To provide logging and error handling, so the above simple case was thorough and reliable;
  • Most importantly, support multiple requests concurrently;
  • Have sensible activities for text AJAX and XML AJAX, these are different cases;

Use cases

  • Be able to supply “auto complete entries” for input boxes;
    • This requires fast end2end processing, and a simple method to get the content onto user display, and the ability to abort, as the old auto-complete is replaced by more recent user typing.
  • Be able to supply PAF lookup values for address capture;
    • This is much cleaner if you can inject data into forms transparently.
  • Be able to asynchronously download binaries for galleries;
    • Requires concurrent access, and a scheme to cache binary objects when they have go to the client.
  • Be able to automatically poll URLs to build Javascript chat clients;
    • Requires polling.
  • Fetching salts, so passwords may be encrypted on the client, and only handled in encrypted form.


There are plenty of articles on the web which entirely omit the concurrent requests requirement, so are operationally useless. Secondly they omit the COOKIEs. These examples demonstrate the requirement for the library. I wanted the resultant library to be “lite weight”, in that it gave to access to AJAX, not tying you in to a developmental environment. Javascript has enough features from LISP that setting up callbacks for the instance specific behaviour is trivial.

As a flat statement the above goals are fairly trivial. However, quite a few browsers loose references , and so leak memory. When the lost references include DOM objects, this quickly becomes a way lock up your machine. The majority of my time was consumed on memory management and making the logging useful. My final edition uses ids for each request, allowing the message stream for a single AJAX request to be distinguished from other HTTP requests. Creating and destroying DOM objects is abit tricky to do cleanly (but necessary so you may use a single process and session for several hours without side-effect).

Due to the “part of the browser” approach of AJAX, this does conflict with tools such as firebug. The logging should be turned off for operational use, but is critical for analysing behaviour on complex pages (where you have AJAX, the number of separate pages required drops quite significantly). When integrated into the design process and assumptions, AJAX is a useful tool. It does need to be a factor in the entire design though. I recommend having two or more rendering modes for site content; your AJAX output - which doesn't need to be a complete HTML document, and a test mode, which provides legal/full pages. The test mode is also useful for devices without good AJAX support such as the phones on sale at the time of writing the library.

Known working for

To be a useful package, I would need to add more infrastructure and retest, not in the least if anyone has changed the default settings in the browser, it may behave differently.
There is a browser dependant maximum number of networking threads that you may open concurrently. Any code may not exceed this.

  • msie 6 and up
    • not tested on msie 9 or 10, as those weren't available at the time.
  • opera 6 and up
    • not tested on opera 10 or 11, as those weren't available at the time.
  • firefox 1.5 and up
  • NOT TESTED on chameleon and safari
  • Was written before Chrome was released, need to test.

Library documentation

API notes

function get_res(url, callbacks, settings, headers)

  • The url is the URL you wish to GET
  • The callbacks are list of event you wish to listen to (see callbacks). This will default, when omitted.
  • The settings are a load of config options for this request (see settings). This will default, when omitted.
  • The headers are any custom headers you want for the request. These are listed as a array hash, name=> value, where the name is as it appears in the HTTP RFC.

If you specify callbacks, the function will operate asynchronously, and return immediately. As noted, omitting the callbacks means it applies the default set, which are good for my purposes. If you specify an empty callbacks array, it will operate synchronously, and return the downloaded data, as a string.

function post_res(url, post, callbacks, settings, headers)
As above, only the post specifies the data to post. This should be URL encoded into a single string, as I couldn't predict what format you would start with. I'll add utility functions to do the grunt work, to the core library, on first usage.

function poll_res(url, freq, callbacks, settings, headers)
As get_res, but the 'freq' value is how often you want to poll. This must be an integer, and is measured in seconds.


The callbacks argument is a hash array which may have the following values:

  • 'ontimeout'
  • 'onconnected'
  • 'onreceived'
  • 'oncomplete'

I may add an 'onerror' callback in later versions.
The values should be function objects.

If the callbacks option is omitted, a default range of values, from the settings array will be will be used.
Each callback is passed the AJAX object, and the settings array.

Settings array

The settings array is a hash array, which may contain the following options:

  • callbacks
    • a second source for callbacks.
  • dont-suppress-cache
    • By default the library adds a random param to the end of the URL, to make reduce likely-hood of cache hits. This disables this option.
  • method
    • HTTP method, i.e. GET or POST (or possibly the other values, but I can't see how to use them in AJAX)
  • timeout
    • The client side time out, how long to wait for responses, measured in seconds
  • chunkid
  • Used in my default event handlers, which DOM element gains the downloaded content.

The system creates the following:

  • id
    • the id of the AJAX object.
  • url
    • cache of the param you passed, used in logging.
  • dead
    • This is a flag, for logging completion of being killed. This prevents any further events from being triggered.
  • abortHandle
    • A reference to the timer resource handle, so you can cancel the timer.
    • The system auto cancels on request completion.

A default set of options is created in create_settings function. It is recommended that this function is overridden to match site wide preferences. The settings can override for instance specific usage.

Sample use


    var yy=new Array();
    get_res('./ajaxb.php', yy);

    var url=“”;
    callbacks=new Array();
    callbacks['ontimeout']=function(ajax, settings) { ... };
    callbacks['oncomplete']=function(ajax, settings) { ... };
    headers=list2array('Accept','image/jpeg,image/png', 'Connection', 'close');
    settings=list2array('timeout', 30, 'method', 'GET', 'colour-gradient1', '#222', 'colour-gradient2', '#ddd');
    get_res(url, callbacks, settings, headers);

    var url=“”;
    var freq = 20;
    callbacks=new Array();
    callbacks['ontimeout']=function(ajax, settings) { ... };
    callbacks['oncomplete']=function(ajax, settings) { ... };
    settings=list2array('timeout', 30, 'method', 'GET');
    poll_res(url, freq, callbacks, settings);


This is available here, under LGPL licence.
I need to add the other implementation and the contextual libraries.

I pulled the library from an old website, but the test cases wheren't installed on that. If any has them, please forward them to me...
This is only valuable as an asset, if you are unable to use jQuery.