Re: logging gconfd state

[Colm Smyth <Colm Smyth ireland sun com>]

Havoc,

>Soliciting opinions: I'm making gconfd save the current set of
>contexts and listeners to a log file, so it can reload said logfile if
>it crashes or exits normally.
>
>I can do this two ways:
> a) save the log synchronously when a client adds a listener, so that 
>    failure to save the log returns an error to the client.
> b) save the log in an idle or timeout, so that adding multiple 
>    listeners results in only one log save, and adding a listener
>    remains cheap.
>
>a) is more robust but I think it's too slow. So I'm probably going to
>do b). But if anyone can think of clever arguments, please post.

No single argument, just some points:

- my guess is that an ORBit round-trip request is slow enough that a 
  synchronous log write in gconfd will not slow listener registration
  excessively.
- the number of listener registrations is low compared with value-gets
- if a thorough performance evaluation identifies it as a bottleneck,
  you have lots of options to speed it up (we can discuss those if
  it looks like we need it)

Colm.

>Havoc
>
>
>
>
>_______________________________________________
>Gconf-list mailing list
>Gconf-list@gnome.org
>http://mail.gnome.org/mailman/listinfo/gconf-list