troggle documentation move para

handbook/troggle/trogspeculate.html

@@ -12,7 +12,7 @@
 
 <pre>
 From: Philip Sargent (Gmail) [mailto:philip.sargent@gmail.com] 
-Sent: 19 April 2020 01:28
+Sent: 19 April 2020 01:28 [original - since edited with extra refs.]
 To: expo-tech@lists.wookware.org
 Subject: vague thoughts about future troggle architecture
 </pre>
@@ -23,14 +23,17 @@ re-partition troggle with all the user interface in the user's browser would
 be utterly horrible using current tools (javascript frameworks: react,
 angular etc.). 
 <p>
-These frameworks get out of date in couple of  years or so. So they don't
+These front-end frameworks get out of date in couple of  years or so. So they don't
 give us the decade-long stability we need to match available maintenance
-effort.
+effort. [ See <a href="https://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks">
+Wikipedia list of javascript frameworks</a>.] With our deep historical perspective ("cough"),
+we can expect this menagerie to sort itself out into a stable, standardised foundation 
+within the next 10 years.
 <p>
 A web API to expose the troggle database (read-only) would allow some keen
 person to write a special-purpose app on a phone, e.g. an entrance-locator
 app, talking directly to the database. But replacing the whole user
-interface does not seem feasible yet.
+interface does not seem feasible yet. In 10 years: probably.
 <p>
 It did occur to me that we are missing a trick: 99+% of the database doesn't
 change except for survey data updates which, apart from during expo, happen
@@ -74,7 +77,7 @@ directories in reality, not 1:1]
 <p>
 <h3>troggle now</h3>
 Troggle is very nearly fully working (not with as many functions as
-originally envisaged admittedly) but very nearly. 
+originally envisaged admittedly) but very nearly [it is now: 8 July 2020]. 
 The QM data display needs writing; but other than that it's in pretty good
 shape. [Ah, yes, we should really add "drawings" as a core concept as well
 as "surveyscans". That will be a bit of work.]
@@ -87,8 +90,7 @@ survex *ref paths.
 
 <h3>Non-django troggle</h3>
 <p>Another possibility is ripping django out of troggle and leaving bare python
-plus a SQL database. This means that programmers would need to understand more SQL
-but would not need to understand "django". Arguably this 
+plus a SQL database [see <a href="trog2030.html">Trog2030 proposal</a>]. This means that programmers would need to understand more SQL but would not need to understand "django". Arguably this 
 could mean that we could gain. 
 <p>Writing our own multi-user code would not be sensible, hence the database. 
 But we could move to a read-only system where the only writing happens on data-import.
@@ -107,6 +109,7 @@ not a function within the python codebase.
 <p>There is a templating engine <a href="https://mozilla.github.io/nunjucks/">Nunjucks</a> 
 which is a port to JavaScript of the Django templating system we use 
 (via <a href="https://palletsprojects.com/p/jinja/">Jinja</a> - these are the same people who do Flask). This would be an obvious thing to use if we needed to go in that direction.
+<p>We need a templating engine because so much of the troggle coorindation output is in tables of data from diffrerent sources, e.g. see <a href=/survexfile/264">all survey data for 264</a>.
 <p>Several organisations have moved their user-interface layer to the browser using
 Nunjucks including <a href="https://service-manual.nhs.uk/design-system/prototyping">
 the NHS digital service</a> and Firefox.