On 07/07/2010 04:41 PM, Amos Jeffries wrote: > On Wed, 07 Jul 2010 13:28:50 -0600, Alex Rousskov > <[email protected]> wrote: >> Hello, >> >> We currently use mgr:info and similar URLs to access "cache manager" >> interface. I know there are plans to change the protocol and/or domain >> name of those URLs, but I want to focus on the URL path (a.k.a. action) >> and SMP. We have several options here: >> >> 1. Keep paths/actions as they are now. Hide individual process state and >> report totals from Squid "as a whole" point of view instead. >> >> 2. Keep paths/actions as they are now. Report individual process state >> and also report totals from Squid "as a whole" point of view, all in one >> response, with appropriate separators to mark per-process and aggregate >> parts. >> >> 3. Allow action parameters to specify which process(es) state should be >> reported. If no parameters were given, just report aggregates. For >> example, mgr:info?process_number=2 will trigger the "info" action for >> forked process #2. >> >> >> We will have #2 supported soon, but since there are many management >> scripts that rely on mgr:info and other actions output format, I think >> #2 will not work as a long-term default. Thus, it seems like our choice >> is between #1 (simple) and #3 (provides per-process information). >> >> I cannot promise #3 support soon, but do you think it is needed at all? >> Any other long-term options/ideas? > > I'm for #3 as a long-term. But would prefer a path field instead of a > query parameter. > ie. mgr:info/2
Why path? Path implies hierarchy so it does not adapt well to future uses (different cache manager parameters for SMP-related or unrelated purposes). Is there a problem with CGI-style parameters that you want to avoid? Thank you, Alex.
