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

[tahoe-lafs]

#386: upload status page should show nicknames
-----------------------------------+----------------------------------------
     Reporter:  warner             |       Owner:  akp             
         Type:  enhancement        |      Status:  new             
     Priority:  minor              |   Milestone:  eventually      
    Component:  code-frontend-web  |     Version:  1.0.0           
   Resolution:                     |    Keywords:  status usability
Launchpad Bug:                     |  
-----------------------------------+----------------------------------------
Changes (by akp):

  * keywords:  status usability review-needed => status usability
  * owner:  davidsarah => akp
  * status:  assigned => new


Comment:

 Appreciate the review, thank you. I hope to take another look at this over
 the weekend.

 Replying to [comment:7 warner]:
 > Some thoughts:
 >  * beware of script injections when rendering the nicknames: they must
 be escaped

 Excellent point, thanks.

 >  * 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").

 OK, I completely misunderstood the purpose of the Unlinked* stuff.  I
 thought it was just for unit testing purposes.  Now I'm reading it over
 again, I realize that's not the case.  It's still not completely clear to
 me what it's for, but I will look at that code again.

 >  * 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.

 Let me take another look at those approaches.  Thanks!

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