On 10/28/2011 12:36 PM, Kinkie wrote: > 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.
Can you start it somewhere so that we can actually see it in action? > 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. Will this be a part of Squid source tarball distribution? It may make sense to keep it separate because it may require separate translations, have a separate release cycle, etc. > 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? Same way we serve icons, I guess. IIRC, Henrik has summarized how Squid-as-web-server should [not] work some time ago, but those changes are probably outside this project scope so I would just reuse icons code for now. If this is difficult, for any reason, just put them somewhere on squid-cache.org and hard-code the URLs in your Javascript, for now. > 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 The difference is minor from Squid code point of view so we can support both, eventually. IIRC, we do that in Co-Advisor, with little code (that we would be happy to copy to Squid). > 3- we need to make the output from cachemgr handlers follow some > common guidelines. Sure. How do you want to post-process that output in Javascript? Some find-and-replace commands using regular expressions? Is it very difficult to have action-specific post-processing? > 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. Indeed. Perhaps this should be discussed on squid-users as well. > This is also in my opinion a prerequisite step to support multiple > output formats in cachemgr. Is there consensus that Squid itself should support multiple output formats? I kind of doubt it is the right thing to do in general. If Squid outputs easy-to-parse, consistent data, other applications can post-process and beautify it in many different ways. > I'm willing to spend the time to do this if we agree that it should be done. Yes, the output should be standardized. Thank you, Alex.
