Ths section is entirely out of date (June 2014), and moved here for historic interest
. @@ -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?Radost Waszkiewicz (CUCC member 2016-2019) proposed a plan for superceding troggle
+ ++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 + +