[Expo-tech] vague thoughts about future troggle architecture

[Mark Shinwell]

Now that I'm just about emerging from dealing with my house refurbishment,
I am hoping to be able to spend some more time thinking about this.  I'd
discussed some ways forward with Martin in the past but there was never the
time to implement them...

Mark

On Sun, 19 Apr 2020 at 01:28, Philip Sargent (Gmail) <
philip.sargent at gmail.com> wrote:

> 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.).
>
> 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.
> 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.
>
> 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.
>
> 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.
> https://github.com/brython-dev/brython
> https://www.brython.info/
>
> 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.
>
> 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
> http://expo.survex.com/handbook/troggle/trogarch.html 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 to-do list..] 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]
>
> 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.]
>
> 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.
>
> Philip
>
>
>
>
> _______________________________________________
> Expo-tech mailing list
> Expo-tech at lists.wookware.org
> https://lists.wookware.org/cgi-bin/mailman/listinfo/expo-tech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wookware.org/pipermail/expo-tech/attachments/20200419/b5d7e324/attachment.htm>