The principle behind the routine is that it waits till the DOM is complete before looking at updating the spans or divs.
And yes, it then does place a request for every token in the html page, which isn't a great deal different to assembling a page that has lots of graphics or other mixed content.
Each div is assigned a class that represents either a refresh or once only request, both of which explain themselves, and the javascript objects to serve them are then setup.
I am surprised that your server cannot cope with 'just' the 22 once only requests.
If you do it the way Aadal has done, you don't need xml refreshes, so you might as well just have a php page that dishes up the data as a once off, that is what I have done with the banner script; I adopted it to read the xml file. But whatever way you look at it, it won't be AJAX !
I can write the routine to have xmlhttprequests instead of htmlresponse, however it does make the code in the web page a lot more complex for the user trying to deploy their web page. Because they will have to know how to associate the xml response with all their tokens - too complex for what I wanted to be a flexible easily deployed solution.
I guess you need to put a new server onto your christmas present list
