[tahoe-dev] [tahoe-lafs] #68: implement distributed introduction, remove Introducer as a single point of failure

[tahoe-lafs]

#68: implement distributed introduction, remove Introducer as a single point of
failure
------------------------------+---------------------------------------------
     Reporter:  lvo           |       Owner:  nobody                                    
         Type:  enhancement   |      Status:  new                                       
     Priority:  major         |   Milestone:  eventually                                
    Component:  code-network  |     Version:  0.2.0                                     
   Resolution:                |    Keywords:  scalability availability introduction gsoc
Launchpad Bug:                |  
------------------------------+---------------------------------------------

Comment (by zooko):

 Replying to [comment:24 writefaruq]:
 > Thanks for corrections. Regarding the reference, that's my intent, not
 to break any reference to it.

 Instead of doing this, please search the codebase for any other reference
 to the {{{self.introducer_furl}}} attribute and change that code to
 reference the new {{{self.introducer_furls}}} attribute instead. Note also
 that any such code will have unit tests that will turn red if your patch
 which removes {{{self.introducer_furl}}} breaks that code, so run the unit
 tests after you have removed {{{self.introducer_furl}}} and after you have
 searched the codebase for other code that uses {{{introducer_furl}}}.

 Likewise in an earlier comment you mentioned:

 > These patches are also backward compatible, not breaking any reference
 to old connected_to_introducer(), but new code should call
 connected_to_introducers() that also supply the status of the single
 introducer.

 This is not the sort of "backward compatibility" that we want. If you are
 adding a new feature in the code or changing a feature in the code then
 instead of leaving the old feature in place in the code in case anyone is
 calling it, we prefer to find all callers and update them.

 On the other hand the things that you said about backward compatibility of
 the tahoe.cfg file ''is'' the sort of "backward compatibility" that we
 want. That has to do with users who might be using an older version of
 Tahoe-LAFS and then upgrade to a newer version which has your patch. We
 want the behavior of the new version to be some good behavior that they
 expected even if they do not make any change to their config files.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/68#comment:28>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized file storage grid