Lat/Long\b\b\b\b\b\b\b\b spacetime coordinates avoid differences names, for instance local spellings. Example: Nuremburg/Nürnberg;
I believe the FIPS location standards apply only to the US. Here's<https://secure.wikimedia.org/wikipedia/en/wiki/Federal_Information_Processing_Standard#Withdrawal_of_geographic_codes> an interesting read. The FIPS standards are a moving target, changeable by the stroke of a politician's pen. Then, any desired human-readable information can be associated with the coordinates. General-relativityingly, Ted On Mon, Jan 16, 2012 at 14:47, Greg Troxel <[email protected]> wrote: > > I'd suggest that a plan of what is needed/wanted is the first step. How do > we do this? The wiki??? I know you main devs seem to use irc, but I'm not > in the US, so I can't easily contribute via that medium (i.e. tz issues). > > I'd say write up a plan and send it to the list. > > As a first though to be knocked about: > - can we use the multi-introducer developments to manage node clustering? > > I don't see how that helps. What I think is needed is: > > 1) Decide if we are going to trust storage nodes to express the > variables that are correlated honestly. I think it's at least near > impossible not to trust them and make progress. > > 2) Decide if we are going to have each node express its correlation > state, or put this in the introducer or similar. I vote for per-node > config. > > 3) Design a mechanism by which a server node can advertise some > properties to clients, like "location=US/Massachusetts/Cambridge/BBN". > Display this in the WUI, and make it obtainable in the CLI. > > 4) Design a first-cut protocol for encoding what we care about into > properties. I sent a zeroth-cut proposal in the previous paragraph :-) > > 5) Design a way to take a list of nodes with their location properties > and make the peer selector/balancer spiffier. I think this is replacing > 'shares.happy' with a more nuanced claim. Perhaps just have a way for > people to write their own rules and link it in, and we can experiment > for a while. A possible rule is "on at least 4 servers that differ in > city". Or "at least 5 servers, with at least 3 cities, and no 2 of > which share a site". This rapidly gets messy. But it can be > individualized code as long as it's easy to write. > > _______________________________________________ > tahoe-dev mailing list > [email protected] > http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > -- GPG/PGP public key: B07F9AAE
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
