++1
:)
Author: jailletc36
Date: Fri Jan 6 07:19:20 2017
New Revision: 1777535
URL:http://svn.apache.org/viewvc?rev=1777535&view=rev
Log:
update
Modified:
httpd/httpd/trunk/STATUS
Modified: httpd/httpd/trunk/STATUS
URL:http://svn.apache.org/viewvc/httpd/httpd/trunk/STATUS?rev=1777535&r1=1777534&r2=1777535&view=diff
==============================================================================
--- httpd/httpd/trunk/STATUS (original)
+++ httpd/httpd/trunk/STATUS Fri Jan 6 07:19:20 2017
@@ -140,6 +140,14 @@ THINGS THAT SHOULD BE CONSIDERED EARLY I
* REST-based administration for existing (balancer/etc) and new dynamic
runtime changes (see above)
+ * Improve the look of generated pages (status, load-balancer...) with dynamic
+ update of the values. Generate HTML5 pages, instead of 3.2, Get rid of
XHTML
+ in the generated pages.
+
+ * Add performance monitoring of the server, of each module (?), in order to
help
+ understanding what worth looking at in order to improve overall
performance.
+
(https://cdn.wp.nginx.com/wp-content/uploads/2016/12/Amplify-Dashboards-page-base-for-filters.png)
+
OLD ISSUES THAT WERE THOUGHT TO BE SHOWSTOPPERS FOR 2.4 BUT OBVIOUSLY WEREN'T:
* Handling of non-trailing / config by non-default handler is broken
Le 18/01/2017 à 10:56, Daniel Gruno a écrit :
On 01/17/2017 07:33 PM, Jim Jagielski wrote:
It all depends on what Bill decides regarding mod_bmx and if
it is something we intent to backport to 2.4.x
Still not sure on how to *use* BMX, or how other modules
"hook in" (right now we have several modules hook into
mod_status so the "how" is well known and documented), so
I would require some sort of docs in addition to the actual
code, of course.
Some JFDI in the meantime; https://httpd.apache.org/server-status :)
JSON: http://httpd.apache.org/server-status?view=json_status
With regards,
Daniel.
On Jan 17, 2017, at 12:35 PM, Luca Toscano <[email protected]> wrote:
2016-11-30 18:54 GMT+01:00 Jim Jagielski <[email protected]>:
I'm thinking about adding JSON support to mod_status...
the "plain" version output really stinks and lacks parity
w/ the info we provide via HTML, and it would be nice
to produce a really easily parseable format.
Thoughts...?
I know it was extensively discussed, but do we have an agreement about a plan
to add this feature? :)
Luca
