Lat/Long\b\b\b\b\b\b\b\b spacetime coordinates avoid differences names, for instance local spellings.<br>Example: Nuremburg/Nürnberg;<br><br>I believe the FIPS location standards apply only to the US.<br><a href="https://secure.wikimedia.org/wikipedia/en/wiki/Federal_Information_Processing_Standard#Withdrawal_of_geographic_codes">Here's</a> an interesting read.  The FIPS standards are a moving target, changeable by the stroke of a politician's pen.<br>

<br>Then, any desired human-readable information can be associated with the coordinates.<br><br>General-relativityingly,<br><br>Ted<br><br><div class="gmail_quote">On Mon, Jan 16, 2012 at 14:47, Greg Troxel <span dir="ltr"><<a href="mailto:gdt@ir.bbn.com">gdt@ir.bbn.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
  I'd suggest that a plan of what is needed/wanted is the first step. How do<br>
  we do this? The wiki??? I know you main devs seem to use irc, but I'm not<br>
  in the US, so I can't easily contribute via that medium (i.e. tz issues).<br>
<br>
</div>I'd say write up a plan and send it to the list.<br>
<div class="im"><br>
  As a first though to be knocked about:<br>
  - can we use the multi-introducer developments to manage node clustering?<br>
<br>
</div>I don't see how that helps.  What I think is needed is:<br>
<br>
1) Decide if we are going to trust storage nodes to express the<br>
variables that are correlated honestly.  I think it's at least near<br>
impossible not to trust them and make progress.<br>
<br>
2) Decide if we are going to have each node express its correlation<br>
state, or put this in the introducer or similar.  I vote for per-node<br>
config.<br>
<br>
3) Design a mechanism by which a server node can advertise some<br>
properties to clients, like "location=US/Massachusetts/Cambridge/BBN".<br>
Display this in the WUI, and make it obtainable in the CLI.<br>
<br>
4) Design a first-cut protocol for encoding what we care about into<br>
properties.  I sent a zeroth-cut proposal in the previous paragraph :-)<br>
<br>
5) Design a way to take a list of nodes with their location properties<br>
and make the peer selector/balancer spiffier.  I think this is replacing<br>
'shares.happy' with a more nuanced claim.   Perhaps just have a way for<br>
people to write their own rules and link it in, and we can experiment<br>
for a while.   A possible rule is "on at least 4 servers that differ in<br>
city".   Or "at least 5 servers, with at least 3 cities, and no 2 of<br>
which share a site".  This rapidly gets messy.  But it can be<br>
individualized code as long as it's easy to write.<br>
<br>_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><font color="#888888"><span style="font-family:tahoma,sans-serif"></span><span style="font-family:tahoma,sans-serif">GPG/PGP public key: B07F9AAE</span><br></font><br>