Separate textual content into multiple pages

peerfinder.py

@@ -175,6 +175,22 @@ def get_targets(uuid):
 def homepage():
     return render_template('home.html')
 
+@app.route('/about')
+def about():
+    return render_template('about.html')
+
+@app.route('/participate')
+def participate():
+    return render_template('participate.html')
+
+@app.route('/privacy')
+def privacy():
+    return render_template('privacy.html')
+
+@app.route('/dev')
+def dev():
+    return render_template('dev.html')
+
 @app.route('/static/<path:path>')
 def static_proxy(path):
     # send_static_file will guess the correct MIME type

templates/about.html

@@ -0,0 +1,84 @@
+{% extends "base.html" %}
+
+{% block content %}
+
+<h2>Why look at latency?</h2>
+
+<h3>The problem of peering quality</h3>
+
+<p>Determining what is a "good" peering in dn42 is quite difficult: many
+criteria come into play, such as latency, jitter, capacity, packet loss,
+stability, or even the price your ISP will pay (peering vs. transit).</p>
+
+<p>On the other hand, a "bad" peering is easy to picture: if you are in
+Paris and peer with somebody in Australia, then you might end up doing
+Paris → Australia → Hamburg if you want to send packets to Germany.  This
+does not feel very efficient.  People usually solve this problem with
+policy routing (local preference and path-prepending).  But it's still a
+good idea to build good links and avoid terrible links.</p>
+
+<p>Of course, you need to build long-distance links sometimes.  Otherwise,
+dn42 would be made of small, independent islands.  This tool can also help
+you to choose the best long-distance links.</p>
+
+<h3>Looking at latency</h3>
+
+<p>Latency is actually a good enough indicator of "distance".  For
+instance, two machines located at the same ISP are expected to have low
+latency towards each other.  On the other hand, a latency above 200 ms
+usually indicates that the two machines are quite far away geographically
+(but not always).</p>
+
+<p>Additionally, latency can vary widely for long-distance links,
+depending on the quality of transit and peering agreements between ISPs.
+For instance, to reach a specific destination in Singapore from France, we
+have the following latency as of September 2014:</p>
+
+<table>
+  <tr>
+    <th>ISP</th>
+    <th>Latency</th>
+  </tr>
+  <tr>
+    <td>Online</td>
+    <td>177 ms</td>
+  </tr>
+  <tr>
+    <td>tetaneutral.net</td>
+    <td>264 ms</td>
+  </tr>
+  <tr>
+    <td>SFR</td>
+    <td>267 ms</td>
+  </tr>
+  <tr>
+    <td>Free</td>
+    <td>365 ms</td>
+  </tr>
+  <tr>
+    <td>OVH</td>
+    <td>402 ms</td>
+  </tr>
+</table>
+
+<p>Of course, this is only a snapshot, and reflects the situation for a
+specific source and destination.  Still, the latency more than doubles
+depending on the ISP, which in this case strongly favours a peering with
+somebody hosted by Online instead of OVH.</p>
+
+<h3>Situations this tool aims to solve</h3>
+
+<p>To sum up, this tool can help in several situations:
+  <ol>
+    <li>Detecting when somebody is in the same datacenter as you, so that
+    it's mostly free to peer</li>
+    <li>When you are far from everybody, find the peering with the lowest
+    latency</li>
+  </ol>
+</p>
+
+<p>By building low-latency links in dn42, it's actually possible to have
+lower latency in dn42 than over the Internet, for the same destination
+(it's called <em>detour routing</em>).</p>
+
+{% endblock %}

templates/base.html

@@ -15,10 +15,10 @@
     <nav id="navigation" role="navigation">
       <ul class="pa0">
 	<li class="pam"><a href="/">Home</a></li>
-	<li class="pam"><a href="/">About</a></li>
-	<li class="pam"><a href="/">Participate!</a></li>
-	<li class="pam"><a href="/">Privacy</a></li>
-	<li class="pam"><a href="/">Development</a></li>
+	<li class="pam"><a href="/about">About</a></li>
+	<li class="pam"><a href="/participate">Participate!</a></li>
+	<li class="pam"><a href="/privacy">Privacy</a></li>
+	<li class="pam"><a href="/dev">Development</a></li>
       </ul>
     </nav>
   </aside> 

templates/dev.html

@@ -0,0 +1,26 @@
+{% extends "base.html" %}
+
+{% block content %}
+<h2>Source code</h2>
+
+<p>The source code is available <a href="https://code.ffdn.org/zorun/peerfinder">here</a></p>
+
+
+<h2>Known issues</h2>
+
+<p>
+Current limitations:
+  <ol>
+    <li>Only the average RTT is measured, we should include other simple
+    statistics (jitter, min/max RTT, packet loss)</li>
+    <li>The API is not documented (just look at the code)</li>
+  </ol>
+Unavoidable facts that cannot be fixed:
+  <ol>
+    <li>Latency measured today might be meaningless tomorrow, as routing
+    on the Internet is always changing</li>
+    <li>Low latency does not guarantee high throughput</li>
+  </ol>
+</p>
+
+{% endblock %}

templates/home.html

@@ -25,154 +25,4 @@ Target:
 </form>
 </p>
 
-<h2>Why look at latency?</h2>
-
-<h3>The problem of peering quality</h3>
-
-<p>Determining what is a "good" peering in dn42 is quite difficult: many
-criteria come into play, such as latency, jitter, capacity, packet loss,
-stability, or even the price your ISP will pay (peering vs. transit).</p>
-
-<p>On the other hand, a "bad" peering is easy to picture: if you are in
-Paris and peer with somebody in Australia, then you might end up doing
-Paris → Australia → Hamburg if you want to send packets to Germany.  This
-does not feel very efficient.  People usually solve this problem with
-policy routing (local preference and path-prepending).  But it's still a
-good idea to build good links and avoid terrible links.</p>
-
-<p>Of course, you need to build long-distance links sometimes.  Otherwise,
-dn42 would be made of small, independent islands.  This tool can also help
-you to choose the best long-distance links.</p>
-
-<h3>Looking at latency</h3>
-
-<p>Latency is actually a good enough indicator of "distance".  For
-instance, two machines located at the same ISP are expected to have low
-latency towards each other.  On the other hand, a latency above 200 ms
-usually indicates that the two machines are quite far away geographically
-(but not always).</p>
-
-<p>Additionally, latency can vary widely for long-distance links,
-depending on the quality of transit and peering agreements between ISPs.
-For instance, to reach a specific destination in Singapore from France, we
-have the following latency as of September 2014:</p>
-
-<table>
-  <tr>
-    <th>ISP</th>
-    <th>Latency</th>
-  </tr>
-  <tr>
-    <td>Online</td>
-    <td>177 ms</td>
-  </tr>
-  <tr>
-    <td>tetaneutral.net</td>
-    <td>264 ms</td>
-  </tr>
-  <tr>
-    <td>SFR</td>
-    <td>267 ms</td>
-  </tr>
-  <tr>
-    <td>Free</td>
-    <td>365 ms</td>
-  </tr>
-  <tr>
-    <td>OVH</td>
-    <td>402 ms</td>
-  </tr>
-</table>
-
-<p>Of course, this is only a snapshot, and reflects the situation for a
-specific source and destination.  Still, the latency more than doubles
-depending on the ISP, which in this case strongly favours a peering with
-somebody hosted by Online instead of OVH.</p>
-
-<h3>Situations this tool aims to solve</h3>
-
-<p>To sum up, this tool can help in several situations:
-  <ol>
-    <li>Detecting when somebody is in the same datacenter as you, so that
-    it's mostly free to peer</li>
-    <li>When you are far from everybody, find the peering with the lowest
-    latency</li>
-  </ol>
-</p>
-
-<p>By building low-latency links in dn42, it's actually possible to have
-lower latency in dn42 than over the Internet, for the same destination
-(it's called <em>detour routing</em>).</p>
-
-
-<h2>I want to participate!</h2>
-
-<p>This tool relies on a pool of workers, all over dn42, that process
-requests, perform ping measurements, and report back the results.  You're
-welcome to add your own machines to the pool!</p>
-
-<h3>Registering a worker</h3>
-
-<p>You need to separately register each computer that will provide
-measurements.  Manual validation is performed for each registration.</p>
-
-<p>The contact information is free-form, and will be shown to users when
-they launch measurements.  This allows users to contact you if they want
-to peer.</p>
-
-<form action="/create/participant" method="POST">
-Machine name (required): <input type="text" name="name" /><br />
-Mean of contacting you, like IRC nick, mail address, ... (optional): <input type="text" name="contact" /><br />
-Country code where this machine is located (optional): <input type="text" name="country" /><br />
-Free-form comment, like tunnel technology (GRE, OpenVPN, ...), or things like &quot;very shitty DSL&quot; (optional): <input type="text" name="comment" /><br />
-<input type="submit" value="Register" />
-</form>
-
-<h3>Measurement script</h3>
-
-<p>The measurement script can be accessed <a href="/script.sh">here</a>.
-You need to edit the UUID.</p>
-
-<h2>Known issues</h2>
-
-<p>
-Current limitations:
-  <ol>
-    <li>Only the average RTT is measured, we should include other simple
-    statistics (jitter, min/max RTT, packet loss)</li>
-    <li>The API is not documented (just look at the code)</li>
-  </ol>
-Unavoidable facts that cannot be fixed:
-  <ol>
-    <li>Latency measured today might be meaningless tomorrow, as routing
-    on the Internet is always changing</li>
-    <li>Low latency does not guarantee high throughput</li>
-  </ol>
-</p>
-
-
-<h2>Source code</h2>
-
-<p>The source code is available <a href="https://code.ffdn.org/zorun/peerfinder">here</a></p>
-
-
-<h2>Privacy</h2>
-
-<p>Privacy for users of this service:
-  <ol>
-    <li>Only participants in the measurement pool have access to your IP
-    address (so that they can ping you, obviously)</li>
-    <li>New participants (see below) are moderated manually</li>
-    <li>Results have an unpredicatble URL.  Of course, if you share the
-    link to the results, anybody can see them.</li>
-  </ol>
-  Privacy for participants in the measurement pool:
-  <ol>
-    <li>Users only get access to the machine name and contact information
-    you provided</li>
-    <li>In particular, users don't get access to your IP address (of
-    course, users can always use tcpdump to see where do the ping requests
-    come from)</lI>
-  </ol>
-</p>
 {% endblock %}

templates/participate.html

@@ -0,0 +1,33 @@
+{% extends "base.html" %}
+
+{% block content %}
+
+<h2>I want to participate!</h2>
+
+<p>This tool relies on a pool of workers, all over dn42, that process
+requests, perform ping measurements, and report back the results.  You're
+welcome to add your own machines to the pool!</p>
+
+<h3>Registering a worker</h3>
+
+<p>You need to separately register each computer that will provide
+measurements.  Manual validation is performed for each registration.</p>
+
+<p>The contact information is free-form, and will be shown to users when
+they launch measurements.  This allows users to contact you if they want
+to peer.</p>
+
+<form action="/create/participant" method="POST">
+Machine name (required): <input type="text" name="name" /><br />
+Mean of contacting you, like IRC nick, mail address, ... (optional): <input type="text" name="contact" /><br />
+Country code where this machine is located (optional): <input type="text" name="country" /><br />
+Free-form comment, like tunnel technology (GRE, OpenVPN, ...), or things like &quot;very shitty DSL&quot; (optional): <input type="text" name="comment" /><br />
+<input type="submit" value="Register" />
+</form>
+
+<h3>Measurement script</h3>
+
+<p>The measurement script can be accessed <a href="/script.sh">here</a>.
+You need to edit the UUID.</p>
+
+{% endblock %}

templates/privacy.html

@@ -0,0 +1,25 @@
+{% extends "base.html" %}
+
+{% block content %}
+
+<h2>Privacy</h2>
+
+<p>Privacy for users of this service:
+  <ol>
+    <li>Only participants in the measurement pool have access to your IP
+    address (so that they can ping you, obviously)</li>
+    <li>New participants (see below) are moderated manually</li>
+    <li>Results have an unpredicatble URL.  Of course, if you share the
+    link to the results, anybody can see them.</li>
+  </ol>
+  Privacy for participants in the measurement pool:
+  <ol>
+    <li>Users only get access to the machine name and contact information
+    you provided</li>
+    <li>In particular, users don't get access to your IP address (of
+    course, users can always use tcpdump to see where do the ping requests
+    come from)</lI>
+  </ol>
+</p>
+
+{% endblock %}