expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2026-02-25 21:55:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

Sorting out troggle design docum.

Browse Source
This commit is contained in:
Philip Sargent
2020-06-04 02:12:54 +01:00
parent 91fc44a486
commit 6e3b781a27
15 changed files with 749 additions and 309 deletions
Download Patch File Download Diff File Expand all files Collapse all files

119
handbook/troggle/trogspeculate.html Normal file
View File

@@ -0,0 +1,119 @@
<!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 <strong>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</strong>.
<h3>Our biggest problem</h3>
We need:
<ul>
<li>something that can be maintained by fewer, less-expert people
<li>who can only devote short snippets of time
<li>without requiring weeks of long-duration deep immersion
</ul>
<h3>Federation of independent scripts</h3>
<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. <strong>At the core there is a common data
model that everything must understand</strong> - 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>
<h3>troggle now</h3>
Troggle is very nearly fully working (not with as many functions as
originally envisaged admittedly) but very nearly.
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>
<h3>Need for separate data-import checking scripts</h3>
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.
<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
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.
Then we could use python 'pickle()' or 'json()' read-only data structures, but we
would need to create all our own indexing and cross-referencing code.
<p>There would be more lower-level code, but the
different segments of the system could be in caving-sensible modules not
django-meaningful modules. And we would not have all the extra
language-like constructs that django introduces e.g. <var>X.objects.set_all()</var>, which
modern editors complain about because it is a django idiom and
not a function within the python codebase.
(We could retain an HTML templating engine though.)
<h3><em>Addendum</em></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>