• Leigh B. Stoller's avatar
    * New libtmcc.pm module that encapsulates the tmcc interface. Most of the · 434a472a
    Leigh B. Stoller authored
      code that was in libsetup has moved into this library, and underwent a
      giant cleaning and pumping up. The interface from your typical perl
      script now looks like this:
      use libtmcc;
      if (tmcc(TMCCCMD_STATUS, "optional arguments", \@tmccresults) < 0) {
          warn("*** WARNING: Could not get status from server!\n");
          return -1;
      foreach my $me (@tmccresults) {
    	print "bite $me";
      The arguments and results are optional values. There is a fourth optional
      value that is a hash of config options (basically converted to command
      line switches passed to tmcc). For example, to set the timeout on an
      individual call, pass a fourth argument like:
    	("timeout" => 5)
      There is also a way to set global options so that all subsequent tmcc
      calls are affected:
    	configtmcc("timeout", 5);
      I'll probably clean this up a bit to avoid the direct strings.
      The result list is a list of strings. Since we are trending away from
      using tmcc to transfer large amounts of data, I think this is okay.
    * A new tmcc.pl which does little more than load libtmcc and use it.
      This will become the new tmcc, with the existing C version becoming a
      backend binary for it.
    * All of the perl scripts in tmcd have been changed to use the new
      library. I left the few uses of tmcc in shell scripts alone since they
      were of the simple variety (mostly "state" command).
    * And again, if you have read this far, you will learn why I bothered with
      all this. Well, the existing code was really bad and it was getting out
      of control. Sort of like a squid that was getting harder to control as
      its rotting tenticles slithered into more and more scripts. Anyway ...
      More important, my goal is to use the libtmcc library to add caching.  I
      have not worked out the details yet, but I am envisioning a configuration
      file, perhaps generated initially by tmcd, of all of the config
      values. If the library finds that file, it sucks the info out of the file
      instead of going to tmcd. Eventually, this config file would be generated
      as part of experiment swapping and stored in the DB, but thats a longer
      term project, and perhaps orthogonal (how we fill the cache is not as
      important as adding the ability to use a cache, right?).
      Note that certain operations (like "state" and "ready") are flagged by
      the library to always bypass the "cache".