Merge branch 'expoweb' of ssh://expo.survex.com/home/expo/expoweb into expoweb

handbook/troggle/trognotes.html

@@ -91,7 +91,7 @@ Most people will not want to read this at all. This is for speleosoftwarearcheol
 <a href="https://gitorious.org/stroggle/stroggle-gitorious-wiki.git/">stroggle-gitorious-wiki</a></br>
 but note that this domain has an expired ertificate so https:// complains.
 
-h3 id="automation">Automation on expo.survex.com</h3>
+<h3 id="automation">Automation on expo.survex.com</h3>
 
 <p>Ths section is entirely out of date (June 2014), and moved here for historic interest</p>.
 
@@ -266,7 +266,7 @@ If I could find some people that agree with this, then we could try to reach a
 compromise on:
 (1) how do we store our data in a file system,
 (2) how do we use this XML (let's do a common spec, but keep it simple)
-(3) how do we aim not to high and not end up dead like CaveXML :)
+(3) how do we aim not too high and not end up dead like CaveXML :)
 
 After we do that, everyone goes away to do their own projects and write their
 own code. Or maybe we have some degree of co-operation in actually writing the
@@ -381,12 +381,78 @@ Backend datafiles:
   (all static info)
  
 Storage:
- non-html or > 200K go in 'files' (PDF, PNG, JPEG, DOC, ODF, SVG)
- convert small 800x600 version into website by default. (matching structure?
+ non-html or > 280K go in 'files' (PDF, PNG, JPEG, DOC, ODF, SVG)
+ convert small 1024x768 version into website by default. (matching structure?
 </pre>
 
 <hr />
 
+<h3 Radost's proposal</h3>
 
+    <p>Radost Waszkiewicz (CUCC member 2016-2019) proposed a plan for superceding troggle</p>
+
+<pre>
+Hey,
+
+on the design sesh we've looked a bit on the way data is organised in the
+loser repo and how to access it via troggle.
+
+A proposal arised that all this database shannaingans is essentially
+unnecessary - we have about 200 caves, about 250 entrances, about 200
+people and couple dozen expos. We don't need efficient lookups at all. We
+can write something which will be 'slow' and make only things we actually
+care about. Similarly I see little gain from doing the html - python himera
+template pages. These contain mainly nested for loops which could just as
+well be written in e.g. python.
+
+I'd advocate following solution:
+- give up on fixing things in troggle
+- have a small number of .py scripts which generate static webpages with
+content we want
+
+Why do this:
+- we don't have multiple intermediate layers all of which are difficult to
+maintain
+- anyone can run this on their machine without need for local vm's
+- to change something there is one thing you change - script that generates
+pages belonging to particular pattern. currently you need to take care of
+parsers, view script, url script, and template
+- it runs offline (just like that as pages are just blocks of literal text
++ some javascript)
+- we never end up with no working copy during expo - run scripts once
+before expedition and put results in /backup and just leave it there till
+next year. Something goes wrong on the daily updated version - we have a
+very easy fallback
+- just one (or very close to it) programming language
+- change to python3 to parse silly chars
+- wayyyy fewer lines of code and substantially better code to comment ratio
+(if this is us writing this now)
+- compatible with all the already existing static pages
+- we can host this on a potato hosting as we're not running anything fancy
+anymore
+- get's rid of the horrifying url rewrites that correspond to no files that
+exist
+
+How much work would this actually take:
+- most likely one script per page type, so far page types that are
+obviously needed:
+--cave index
+--individual cave descriptions
+--logbooks
+- more than half of the parsers are already rewriten by me and can be
+changed to do this instead of modifying SQL database with minimal effort
+- html/css side of things already exists, but it would be nice to go for a
+more modern look there as well
+
+Things this solution doesn't solve:
+- no webpage-based 'wizzard' for creating caves and such (did people use it
+much? do we care?) -> maybe 'send an email to this address' is the ultimate
+solution to this
+- uploading photos is still difficult (in the sense that they don't get
+minified automatically)
+
+Rad
+
+</pre>
 </body>
 </html>