From 500f536d33f7a56fd4962b5e64584deff94e26d7 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Tue, 11 Dec 2012 04:17:36 +0000
Subject: [PATCH] Migrated glossary and performance improvements

---
 i2p2www/pages/global/nav.html                    |  2 ++
 .../pages/site/support}/glossary.html            |  2 +-
 .../pages/site/support/performance/future.html   | 16 ++++++----------
 .../pages/site/support/performance/history.html  |  6 +++---
 4 files changed, 12 insertions(+), 14 deletions(-)
 rename {www.i2p2/pages => i2p2www/pages/site/support}/glossary.html (91%)
 rename www.i2p2/pages/performance.html => i2p2www/pages/site/support/performance/future.html (90%)
 rename www.i2p2/pages/performance-history.html => i2p2www/pages/site/support/performance/history.html (96%)

diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index 14f1ad77..e78a5b2a 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -72,6 +72,8 @@
   <li class="has-sub"><a href="#"><span>{{ _('Support') }}</span></a>
     <ul>
       <li><a href="{{ site_url('support/faq') }}"><span>{{ _('FAQ') }}</span></a></li>
+      <li><a href="{{ site_url('support/glossary') }}"><span>{{ _('Glossary') }}</span></a></li>
+      <li><a href="{{ site_url('support/performance') }}"><span>{{ _('Performance') }}</span></a></li>
       <li><a href="{{ site_url('support/contact') }}"><span>{{ _('Contact us') }}</span></a></li>
       <li><a href="http://{{ i2pconv('forum.i2p') }}/"><span>{{ _('Forums') }}</span></a></li>
       <li><a href="http://{{ i2pconv('trac.i2p2.i2p') }}/"><span>Trac</span></a></li>
diff --git a/www.i2p2/pages/glossary.html b/i2p2www/pages/site/support/glossary.html
similarity index 91%
rename from www.i2p2/pages/glossary.html
rename to i2p2www/pages/site/support/glossary.html
index 57866852..9a675494 100644
--- a/www.i2p2/pages/glossary.html
+++ b/i2p2www/pages/site/support/glossary.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Glossary{% endblock %}
 {% block content %}
 This page lists often-used terminology when discussing I2P and cryptography.
diff --git a/www.i2p2/pages/performance.html b/i2p2www/pages/site/support/performance/future.html
similarity index 90%
rename from www.i2p2/pages/performance.html
rename to i2p2www/pages/site/support/performance/future.html
index c104206e..a07d3571 100644
--- a/www.i2p2/pages/performance.html
+++ b/i2p2www/pages/site/support/performance/future.html
@@ -1,19 +1,15 @@
-{% extends "_layout.html" %}
-{% block title %}Performance{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}Future Performance Improvements{% endblock %}
 {% block content %}
 Updated August 2010, current as of router version 0.8
 
-<p>Probably one of the most frequent things people ask is "how fast is I2P?",
-and no one seems to like the answer - "it depends".  After trying out I2P, the
-next thing they ask is "will it get faster?", and the answer to that is a most
-emphatic <b>yes</b>.</p>
 <p>There are a few major techniques that can be done to improve the perceived
 performance of I2P - some of the following are CPU related, others bandwidth
 related, and others still are protocol related.  However, all of those
 dimensions affect the latency, throughput, and perceived performance of the
 network, as they reduce contention for scarce resources.  This list is of course
 not comprehensive, but it does cover the major ones that are seen.</p>
-<p>For past performance improvements see the <a href="performance-history.html">
+<p>For past performance improvements see the <a href="{{ site_url('support/performance/history') }}">
 Performance History</a>.
 
 <h2>Better peer profiling and selection</h2>
@@ -36,7 +32,7 @@ tuning on what we actually send - how many peers we bounce back (or even if we
 bounce back a reply), as well as how many concurrent searches we perform.</p>
 
 <h2>Session Tag Tuning and Improvements</h2>
-<p>The way the <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> algorithm
+<p>The way the <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> algorithm
 works is by managing a set of random one-time-use 32 byte arrays, and expiring
 them if they aren't used quickly enough.  If we expire them too soon, we're
 forced to fall back on a full (expensive) ElGamal encryption, but if we don't
@@ -48,12 +44,12 @@ efficiently tune the lifetime of the tags, replacing the ElGamal encryption with
 a trivial AES operation.</p>
 <p>
 Additional ideas for improving Session Tag delivery are described on the
-<a href="how_elgamalaes.html#future">ElGamal/AES+SessionTag page</a>.
+<a href="{{ site_url('docs/how/elgamalaes') }}#future">ElGamal/AES+SessionTag page</a>.
 </p>
 
 
 <h2 id="prng">Migrate sessionTag to synchronized PRNG</h2>
-<p>Right now, our <a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a> 
+<p>Right now, our <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> 
 algorithm works by tagging each encrypted message with a unique random 
 32 byte nonce (a "session tag"), identifying that message as being encrypted 
 with the associated AES session's key. This prevents peers from distinguishing 
diff --git a/www.i2p2/pages/performance-history.html b/i2p2www/pages/site/support/performance/history.html
similarity index 96%
rename from www.i2p2/pages/performance-history.html
rename to i2p2www/pages/site/support/performance/history.html
index a65fe726..5c7fc0f3 100644
--- a/www.i2p2/pages/performance-history.html
+++ b/i2p2www/pages/site/support/performance/history.html
@@ -1,8 +1,8 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Performance History{% endblock %}
 {% block content %}
 <p>Notable performance improvements have been made using the techniques below.
-There is more to do, see the <a href="performance.html">Performance</a> page
+There is more to do, see the <a href="{{ site_url('support/performance') }}">Performance</a> page
 for current issues and thoughts.</p>
 
 <h2>Native math <b>[implemented]</b></h2>
@@ -99,7 +99,7 @@ message, and Bob piggybacked his first reply with the ACK - and perhaps also
 included the CLOSE flag - transient streams such as HTTP requests could be
 reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.</p>
 
-<h2>Implement full streaming protocol</h2> [<a href="streaming.html">implemented</a>]
+<h2>Implement full streaming protocol</h2> [<a href="{{ site_url('docs/api/streaming') }}">implemented</a>]
 <p>The ministreaming protocol takes advantage of a poor design decision in the
 I2P client protocol (I2CP) - the exposure of "mode=GUARANTEED", allowing what
 would otherwise be an unreliable, best-effort, message based protocol to be used