[rrd-developers] implementing portable format

[kevin brintnall]

On Sat, Nov 01, 2008 at 09:33:46AM +0100, Tobias Oetiker wrote:
> > Maybe we can start to tidy up for 1.4 now (while the storage code is
> > relatively stable) and target the storage changes (portable format,
> > different backends) for 1.5?
> 
> yes you are right, this might be sensible ... release often,
> release early ...
> 
> what work do you see for the cached ?

Here's what I'm currently pondering..  I'm interested in your thoughts on
the new features...

-----------------------------------------------------------------

NEW FEATURES:

* UPDATEV support?  It would require the daemon to keep a copy of the RRD
  header of each file in memory, and perform the same calculations that
  will ultimately be performed on the real file.

  - higher memory utilization
  - lots of disk reads when the working set is being "primed"
  ? when an update causes a CDP to be written, does that require access to
    the PDP rows or just the info in the header?
  - If it does require reading the rows, the daemon can only efficiently
    return the PDP updates (not CDP) during UPDATEV response

* expose BATCH mode to API/bindings?
  (for my setup I wrote my own protocol speaker and talk directly to the
  daemon for high update rate)

  + enables higher update rates
  - client won't get return codes
    (i.e. you can't know a FLUSH has completed while you're still in BATCH
    mode).

-----------------------------------------------------------------

These are pretty straightforward...

MISC:

* memchr vs. strchr
  + validate correct behavior if rrdcached receives a '\0' on input

* check strncpy() and snprintf() correct use of sizeof() bounds

* "quit" command (to close connection)

* journal_write: pass sock, move "if(sock!=NULL)" logic into function

-----------------------------------------------------------------

cheers,

-- 
 kevin brintnall =~ /kbrint at rufus.net/