MIME-Version: 1.0
In-Reply-To: <rt-3.8.6-60453-1284580962-1742.22096-5-0@isc.org>
References: <RT-Ticket-22096@isc.org> <38C0BFD50092414E900DEE15F8976FE0@sb.litts.net> <rt-3.8.6-60453-1284580962-1742.22096-5-0@isc.org>
Message-ID: <237D0B8C2FAA40AFA48FEC40FE1DF516@sb.litts.net>
Content-Type: text/plain; charset="utf-8"
Subject: RE: [ISC-Bugs #22096] FW: Statistics channel patch 
Thread-Index: ActVEPsNHiXTYchfS7ClKZo1M9bHzAAcm9Eg
Date: Thu, 16 Sep 2010 05:59:05 -0400
To: <bind-suggest@isc.org>
Content-Transfer-Encoding: 7bit
From: "Timothe Litt" <litt@acm.org>
RT-Message-ID: <rt-3.8.6-60445-1284631165-926.22096-0-0@isc.org>
Content-Length: 2629

One more thought - another thing that might be useful would be a way to
register for event notifications; specifically configuration changes.

If that were possible, I could have a monitoring process that registered for
config changes (e.g. zones added/removed, or status changed, or...), and
only fetched the XML when it started or was notified.  It would then update
the GUI data - or whatever.  The caller would do the usual html stuff to
keep the connection open.

That might look like:
  /views/*/zones?view.zone.type=user&DataClass=config&RegisterForUpdates=1

In this case, named would send the xml, but keep the query on a trigger
list.  When the config was updated (or if status was selected and status
chaged), it would regenerate the XML and send it again (server push style).


For statistics, I think there would be less benefit - one could have a
RefreshInterval - but the client can keep a timer just as easily and simply
ask again.

Something like this would reduce the load on everyone - named isn't serving
redundant queries, and its load scales with the number of applications (not
the number of application instances), the monitor only wakes when something
happens, and the GUI (or other data collector) simply reads the cached,
pre-processed data.

This is more than I currently require, but might well be better for the
wider community.

FWIW,


Timothe Litt
ACM Distinguished Engineer
---------------------------------------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

  
-----Original Message-----
From: Michael Graff via RT [mailto:bind-suggest@isc.org] 
Sent: Wednesday, September 15, 2010 16:03
To: litt@acm.org
Subject: [ISC-Bugs #22096] FW: Statistics channel patch 

Thank you for your feedback on the XML channel.

>From a design point of view, I intentionally did not split the data 
>apart but
instead returned the whole thing. This was intentional until we could make
it into a more RESTful style.

It is probably time to actually take on the work of splititng the data into
chunks. A simple RESTful API for gathering information about a server, in my
mind anyway, was along the lines of:

/views -- returns a list of views
/views/_default -- returns information about a specific view
/views/_default/zones -- returns a list of zones in a particular view
/views/_default//zones/isc.org -- returns detailed information about this
particular zone

and so on. I am not certain if the /config, /stats, or /status information
should be before or after the URIs in this simple example. My gut tells me
after.

--Michael