cachemgr output normalization

Hi all,
  Now that cachemgr happily responds to proper http requests, I've
started toying with a browser-based, all-javascript/DHTML cachemgr.cgi
replacement.
I have a first beta available in launchpad at
lp:~kinkie/squid/cachemgr-js . It currently requires help from squid
via a rproxy setup to serve the two HTML and one javascript file, but
if we can have squid serve them internally, it'll be a no-brainer for
single-instance monitoring.

There's a few open points which need a bit of thinking though:
1- what is the best way to serve a few static html and javascript files?
2- does cachemgr get engaged only via GET method or can we have it
also answer to POST requests? The reason is that GET requests in
javascript are subject to a same-origin policy, while POST are not. It
would allow for multi-server monitoring and it would make point 1 a
nice-to-have and not a requirement
3- we need to make the output from cachemgr handlers follow some
common guidelines.

Point 3 deserves a bit of explanation: excluding actions (reconfigure,
offline_toogle etc), cachemgr mostly outputs sets of tables or sets of
free-form text lines; the latter is for instance used for outputting
the config. The problem with tables is that they are inconsistently
formatted: some pages (for instance ipcache or internal dns or
histograms) use spaces and printf-style formatting, others (e.g.
counters) use "key = value" formatting, others (refresh) use tab
separators, others (mempools) use a mixture of tables and
printf-formatting, others use complex textual representations (e.g.
in-transit objects).

I would like to propose that we adopt a standard style, by making a
policy that that a table is a table is a table: all tabular format
should be tab-delimited lf-terminated rows. This poses a problem of
compatibility with third-party software. We can either have a
transition phase where we duplicate actions, or we can just decide
that we don't have the resources to care, and we just warn the authors
that we know of about our intentions so that they have time to adapt.

This is also in my opinion a prerequisite step to support multiple
output formats in cachemgr.
I'm willing to spend the time to do this if we agree that it should be done.

Thanks,

-- 
    /kinkie