[tahoe-lafs-trac-stream] [tahoe-lafs] #1363: refactor storage_client.py, use IServer objects instead of rrefs

[tahoe-lafs]

#1363: refactor storage_client.py, use IServer objects instead of rrefs
------------------------+---------------------------------------------------
     Reporter:  warner  |       Owner:  zooko        
         Type:  task    |      Status:  new          
     Priority:  major   |   Milestone:  undecided    
    Component:  code    |     Version:  1.8.2        
   Resolution:          |    Keywords:  review-needed
Launchpad Bug:          |  
------------------------+---------------------------------------------------
Changes (by warner):

  * keywords:  => review-needed
  * owner:  warner => zooko
  * status:  assigned => new


Comment:

 ok, -patch2 is ready for review. This one is a darcs patch bundle with 20
 individual patches, intended to isolate each change for easier review.
 Many of them are improving internal names, like referring to "servers"
 instead of "peers", or fixing the uploader to clearly distinguish between
 a Server object and a !ServerTracker (which were sufficiently confusing
 before that we had a bunch of {{{assert isinstance(server,
 ServerTracker)}}} checks). There's also some dead-code removal, which made
 subsequent refactoring easier.

 The bulk of the changes are intended to reduce the use of
 {{{get_serverid()}}}. Previously, a lot of the code has been passing
 around {{{(tubid, rref)}}} tuples: the goal is to pass around
 {{{IServer}}} objects instead. The first step is to replace those tuples
 with {{{(s.get_serverid(), s.get_rref())}}}, but the second step (which
 this patch starts to implement) is to push that change further down into
 the code, delaying the conversion from {{{IServer}}} to {{{serverid}}}
 until the last possible moment, and in many cases not doing it at all.
 This means that many data structures which were previously indexed by
 serverid are now indexed by {{{IServer}}} instance.

 This patch doesn't complete the job, but it gets a significant amount of
 the way there. It doesn't touch the mutable code at all: I'm hoping to
 review and land #393 before attempting any refactoring of
 {{{mutable/*.py}}}, to make life easier.

 The tree should pass all tests and be pyflakes clean after applying each
 patch in this series.

 note to self: I still need to implement zooko's recommendations from
 comment:7 in a later patch.

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