mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-12-02 14:51:58 +00:00
95 lines
4.7 KiB
HTML
95 lines
4.7 KiB
HTML
|
<!DOCTYPE html>
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<title>Handbook Troggle Architecture Speculations</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
|
||
|
|
</head>
|
||
|
|
<body><style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
|
||
|
|
<h2 id="tophead">CUCC Expedition Handbook</h2>
|
||
|
|
<h1>Troggle Architecture Speculations</h1>
|
||
|
|
|
||
|
|
|
||
|
|
<pre>
|
||
|
|
From: Philip Sargent (Gmail) [mailto:philip.sargent@gmail.com]
|
||
|
|
Sent: 19 April 2020 01:28
|
||
|
|
To: expo-tech@lists.wookware.org
|
||
|
|
Subject: vague thoughts about future troggle architecture
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
At our last virtual pub Sam confirmed that using today's tools to
|
||
|
|
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
|
||
|
|
give us the decade-long stability we need to match available maintenance
|
||
|
|
effort.
|
||
|
|
<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.
|
||
|
|
<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
|
||
|
|
only every week or so. And the database is only 10 MB so is entirely
|
||
|
|
feasible to copy absolutely everything into the browser except for scanned
|
||
|
|
images and photos.
|
||
|
|
<p>
|
||
|
|
So we could partition troggle so that all the user display bits run in the
|
||
|
|
browser (or a progressive web app) using a python interpreter running in
|
||
|
|
javascript. [yeah, expofiles would need some subset labelled as needing to
|
||
|
|
be forcibly downloaded, but the rest coming only on demand.] Some django
|
||
|
|
enthusiast must have done this already surely ? Ah yes, Brython.<br>
|
||
|
|
<a href="https://github.com/brython-dev/brython">github.com/brython-dev/brython</a><br>
|
||
|
|
<a href="https://www.brython.info/">www.brython.info</a>
|
||
|
|
<p>
|
||
|
|
Which is fun, but not useful. And not just because it is immature. None of
|
||
|
|
this addresses our biggest problem: devising something that can be
|
||
|
|
maintained by fewer, less-expert people who can only devote short snippets
|
||
|
|
of time and not long-duration immersion.
|
||
|
|
<p>
|
||
|
|
I know Wookey has been thinking of a loose federation of independent scripts
|
||
|
|
working on the same data, but the more I look at troggle and the tasks it
|
||
|
|
does the less I feel that would work. At the core there is a common data
|
||
|
|
model that everything must understand - and the only unambiguous way of
|
||
|
|
presenting that data model is working code, e.g. see
|
||
|
|
<a href="http://expo.survex.com/handbook/troggle/trogarch.html">Troggle architecture</a> and click on the image
|
||
|
|
to see a bigger copy. [It is out of date - if someone can quickly generate
|
||
|
|
an update that would be nice. It's on my <a href="../computing/todo.html">to-do list..</a>] Much of what
|
||
|
|
wallets.py does (originally by Martin Green) is in troggle already - but
|
||
|
|
better. [There is a many:many relationship between svx files and wallet
|
||
|
|
directories in reality, not 1:1]
|
||
|
|
<p>
|
||
|
|
Troggle is very nearly fully working (not with as many functions as
|
||
|
|
originally envisaged admittedly) but very nearly. There are several
|
||
|
|
import/parsers which are aborting without producing error messages, so most
|
||
|
|
of the survey blocks don't get loaded where they actually get displayed, and
|
||
|
|
the surveyscan images only appear as filename strings which are not checked
|
||
|
|
for referential integrity, so we are missing a consistency check there, and
|
||
|
|
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.]
|
||
|
|
<p>
|
||
|
|
The one thing external scripts would be really useful for is syntax checking
|
||
|
|
and reference checking prior to import. I have found some weird and
|
||
|
|
wonderful filename paths inside the tunnel and therion drawings, and in
|
||
|
|
survex *ref paths.
|
||
|
|
<p>
|
||
|
|
<h3>Addendum</h3>
|
||
|
|
<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>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.
|
||
|
|
|
||
|
|
<hr />
|
||
|
|
Go on to: <a href="trogarch.html">Troggle architecture</a><br />
|
||
|
|
Return to: <a href="trogintro.html">Troggle intro</a><br />
|
||
|
|
<hr />
|
||
|
|
</body>
|
||
|
|
</html>
|