#778: "shares of happiness" is the wrong measure; "servers of happiness" is
better
---------------------------------------+------------------------------------
Reporter: zooko | Owner: warner
Type: defect | Status: new
Priority: critical | Milestone: 1.6.0
Component: code-peerselection | Version: 1.4.1
Keywords: reliability review-needed | Launchpad_bug:
---------------------------------------+------------------------------------
Comment(by zooko):
Replying to [comment:146 kevan]:
> I'm not sure what I think about making preexisting_shares a map to a set
of peerids. It would remove the need for {{{should_add_server}}}, but
would also make the end calculations more complicated. I'll think about
that when I've worked through the rest of your comments.
Okay, think about it!
> (of course, if I'm wrong in my last comment, maybe it makes sense to do
that regardless of complexity)
Yeah, there are two notions of "complexity". One is computational --
basically "the size of the code for the shortest implementation of this".
The other is cognitive -- basically "the difficulty for the Tahoe-LAFS
hackers to learn this and then to hold it correctly in their heads".
It ''might'' be the case that making both data structures be maps from
shareid to set of serverid would make the algorithm "simpler" in the
latter way -- easier to comprehend. I'm not sure.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:148>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
_______________________________________________
tahoe-dev mailing list
[email protected]
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
