[tahoe-lafs-trac-stream] [tahoe-lafs] #1385: stop respecting the pre-v1.3.0 configuration files

[tahoe-lafs]

#1385: stop respecting the pre-v1.3.0 configuration files
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:
         Type:           |     Status:  new
  enhancement            |  Milestone:  1.9.0
     Priority:  minor    |    Version:  1.8.2
    Component:  code-    |   Keywords:  docs configuration defaults
  nodeadmin              |  usability
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by zooko):

 There's one issue I've found: foolscap (v0.6.1) can't accept a set of log
 gatherer furls through its Python API—it can accept at most one that way
 and it can accept any number by reading a file and finding one furl per
 line in that file. I've opened [http://foolscap.lothar.com/trac/ticket/176
 foolscap ticket 176] to request that a future version of foolscap accept
 any number of log gatherer furls through its Python API.

 In the meantime we could either:

 1. remove the ability to have multiple log gatherers from Tahoe-LAFS,
 which would be a regression (albeit this is probably a feature that nobody
 currently uses), or

 2. we could preserve the file {{{$BASEDIR/log_gatherer.furl}}} for another
 major release (unioning with the contents of the singleton
 {{{log_gatherer.furl}}} key in {{{$BASEDIR/tahoe.cfg}}}), or

 3. we could extend the {{{tahoe.cfg}}} key to accept multiple furls
 (whitespace separated), treat {{{$BASEDIR/log_gatherer.furl}}} like all
 the other old-style configuration files by warning about its existence and
 ignoring its contents, and use a different filename such as
 {{{$BASEDIR/foolscap/log_gatherer_furls.txt}}} to transmit the set of
 furls from {{{tahoe.cfg}}} to foolscap.

 The advantage of approach 3 is that the user configures log gatherer furls
 just like she configures everything else: in {{{$BASEDIR/tahoe.cfg}}}.
 {{{$BASEDIR/foolscap/log_gatherer_furls.txt}}} is documented as being
 "internal use only" and not for users to read or edit. (We might rm it
 after letting foolscap read it just to drive the point home.)

 Someday when all users have upgraded to a version of foolscap that
 provides [http://foolscap.lothar.com/trac/ticket/176 foolscap ticket 176],
 then we could stop using the temporary file hack to communicate the set of
 furls from {{{tahoe.cfg}}} into foolscap.

 So, I'm currently implementing approach 3, but I'll listen if anybody has
 a strong opinion to the contrary.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1385#comment:6>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage