[tahoe-dev] [tahoe-lafs] #386: upload status page should show nicknames

tahoe-lafs trac at tahoe-lafs.org
Tue Sep 21 00:53:35 UTC 2010


#386: upload status page should show nicknames
-----------------------------------+----------------------------------------
     Reporter:  warner             |       Owner:  davidsarah                    
         Type:  enhancement        |      Status:  assigned                      
     Priority:  minor              |   Milestone:  eventually                    
    Component:  code-frontend-web  |     Version:  1.0.0                         
   Resolution:                     |    Keywords:  status usability review-needed
Launchpad Bug:                     |  
-----------------------------------+----------------------------------------

Comment (by warner):

 Some thoughts:
  * beware of script injections when rendering the nicknames: they must be
 escaped
  * creating the Uploader with a history= object (instead of passing one in
 to each upload() call) seems reasonable, although in the long run I think
 we'd like to get rid of the Uploader. I don't know what will replace it
 yet, though, so {{{Uploader(history=)}}} for now seems fine.
  * {{{UnlinkedStorageBroker}}} is a bit confusing, it sounds like it
 involves "unlinked files". Maybe "Assisted Storage Broker"? But actually,
 clients who are using a Helper may know about those servers anyways, so I
 think they should probably use their own storagebroker instead of stubbing
 out the nicknames. If we do stub out the names, the stubs should make that
 obvious (i.e. "UNKNOWN").
  * overall I'd like to find a way to make the patch a bit less.. invasive,
 I guess. It's unfortunate that so many of the web/status.py constructors
 have to be touched. Two other approaches that come to mind, not sure if
 either one is feasible and/or any better:
   * use the {{{self.site.remember(obj, INTERFACE)}}} mechanism to attach
 an object to each {{{Request}}}. If this works (and I remember having
 problems with it in the past), then we could pass the Client, the History
 object, and probably the Storage Broker too, all passed sort of ambiently
 along with the Request, rather than explicitly down through every single
 constructor. OTOH, POLA might be achieved better with explicit
 constructors.
   * move responsibility for nickname-association over to the Uploader: it
 has the storagebroker already. so it could extract a nickname early and
 stash it in the record.

 In the longer run, I think I might want the History record to point to a
 {{{StorageClient}}} instance, rather than merely its nodeid, in which case
 {{{web/status.py}}} would just ask it for an ID or a nickname directly.

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


More information about the tahoe-dev mailing list