[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: back-monitor and dynamically generated entries...
On Tue, Mar 16, 2004 at 10:12:33AM +0100, Pierangelo Masarati wrote:
> I have a doubt about dynamically generated/updated entries, like those in
> back-monitor (but this could apply as well to dynamic directory services
> as of RFC2589), and couldn't find any hints in standard tracks: any time a
> "dynamic" entry is updated, which means that it is being requested by some
> operation for some purpose, should I update the "modifyTimeStamp" to
> reflect the time of its last update (and possibly "modifiersName" set to
> the rootdn of the monitor database, if any)?
>
> For instance, if I ask for "cn=Start,cn=Time,cn=Monitor", no update takes
> place; on the contrary, if I ask for "cn=Current,cn=Time,cn=Monitor", the
> "monitorTimeStamp" gets updated to the current time, so I think I should
> update the "modifyTimeStamp" as well...
I think you are right: modifyTimeStamp should be updated in such
cases. The benefits I see are:
1) It helps any opportunistic cache code in clients to make
better decisions.
2) It could allow monitor processes to calculate rates-of-change
more accurately in the face of variable latency links. SNMP
clients often do this - they ask for the number of clockticks
since boot as part of each request, so that the data they receive
is effectively timestamped.
This argues for 'updating' the modifyTimeStamp *before*
returning it... Should be no problem as it will always be set
to the current server time if volatile data is being returned.
3) If that is the behaviour in other backends then it seems right
for monitor to follow the same rules.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------