Centralize configuration parameters in a Key/Value store

[pjcuadra]

No description provided.

[jaharkes]

Although this is the direction I think I would like to go with config, I am currently not convinced this is the right change at the moment.

[jaharkes]

A little odd to have the venus default config in coda-src/util/

Would we end up with the codasrv, updateclnt, updatesrv, auth2 configs here as well?

Or, if venusconf is venus specific, it probably shouldn't be in /util/

[pjcuadra]

Thanks. That's actually wrong. It should be in coda-src/util/. I put it there first for convenience and forgot to move it into coda-src/venus/.

[jaharkes]

Why are some variables static globals resolved at init time, while others are processed in-line? Why is there a distinction between f.i. sftp_windowsize and rpc2_retries?

[pjcuadra]

The reason is simple. If the variable is used all over the .cc, I decided to declare a static global. If it's only needed once I tent to process it in-line. Do you believe that we should declare all static? I was also thinking to do something like;

struct comm_config {
    int COPModes;
    int sftp_windowsize;
    int sftp_sendahead;
    int sftp_ackpoint;
    int sftp_packetsize;
    int rpc2_retries;
   ...
}

static struct comm_config config = {0, UNSET_WS, UNSET_SA, UNSET_AP ....};

... 

void CommInit() {
    config.COPModes         = GetVenusConf().get_int_value("copmodes");
    config.sftp_windowsize  = GetVenusConf().get_int_value("sftp_windowsize");
    config.sftp_sendahead   = GetVenusConf().get_int_value("sftp_sendahead");
    config.sftp_ackpoint    = GetVenusConf().get_int_value("sftp_ackpoint");
    config.sftp_packetsize  = GetVenusConf().get_int_value("sftp_packetsize");
    config.rpc2_retries     = GetVenusConf().get_int_value("RPC2_retries");
    ...
}

This for every sub-system would be consistent and expressive.

[jaharkes]

only spaces in comments updated in this file

[jaharkes]

why bother with a .cc when everything is in the header file.

[pjcuadra]

I normally like to leave the placeholder for extensions, and try to have a .cc and .h per class. But I'll remove it.

[jaharkes]

Are these (codaconfparser, codaconffileparser, codaconfcmdlineparser)'s actually used anywhere?

[pjcuadra]

Yes, CodaConfFileParser and CodaConfCmdLineParser inherit from CodaConfParser and are used in venus.cc.

[pjcuadra]

Even if this isn't the right change at the moment, I'd like to push this a little forward to a point where it's consistent and merge-ready.

I'd just like mention that with this we invert the break the dependency loop between main (venus.cc) and the rest of the program. Having venus.cc depending on the rest of the program but not vice-versa.

This improves testability and decoupling substantially. For instance, I was able to test CacheFile completely independent from everything else.