Project Spud

[Olly Betts]

Hi folks,

I've put up a web page http://www.survex.com/spud.html on the plans for
Survex 2.0, as it's easier to update and add some design stuff as things
progress.  Here's a text version for your convenience.

Cheers,
Olly

===

   It's now (August 2000) slightly over ten years from the creation of
   the original seed which grew into Survex. It was July 1990 and I
   (Olly) was on my first CUCC Austria expedition. We were using some
   survey software called Surveyor87 - it was pretty good, but the
   graphics could at best be described as "sluggish" so I sat around in
   the [1]potato hut at base camp and knocked together a BBC BASIC and
   ARM assembler cave viewer, which later evolved into caverot.
   
   A decade later, almost to the day, the plan for a new incarnation of
   Survex began to gel in that same wooden hut. The other main recent
   contributors to this plan were Mark Shinwell, Phil Underwood, and
   Wookey. But I've been absorbing ideas and suggestions from more people
   than I can sensibly list here over the past decade.
   
   After some beer we came up with the name Visual Survex++ 2000
   Professional Platinum Millennium Edition. Bleary eyed the next morning
   Project Spud seemed a better idea (spud being English slang for
   Potato).
   
   The plan is to take the current incarnation of Survex to 1.0, and then
   move active development to project spud. Survex 1.0 would continued to
   be maintained with bug fixes and minor improvements.
   
   Before getting too deep into technical details I'll list some of the
   major benefits of project spud for the end-user:
     * Seamlessly integrated GUI
     * Third party extensions available in plug-in form
     * Only modules and extensions you use get loaded, reducing memory
       usage
     * Ability to read survey data in a mixture of the native format,
       interchange formats, and formats of other survey software
     * Printing using MS Windows printer drivers
     * Built in revision history for a data set; ability to look at what
       the data looked like at any point in the past
     * It'll be here in substantially less than a decade this time -
       hoping to reach 2.0 by the end of 2001
       
   If you aren't interested in how this gets done, you can safely tune
   out now.
   
   A couple of notable problems with the current version are:
     * The lack of a GUI. It's not where my interests or talents lie, so
       it's been rather neglected. Various people have written cave
       viewers, and Phil Underwood has written a fully fledged front-end
       (Chasm). But the current architecture makes it hard to integrate
       these seamlessly.
     * Much of the code isn't modular enough to be easy to extend in ways
       we want - e.g. the string of problems with the new code to split
       the network at articulation points. Also the code to interpret
       .svx files is hard to use separately so anyone writing a program
       which reads .svx files takes the path of least resistance and
       writes their own. But then their program needs updating whenever
       the .svx format is extended (e.g. the HTO exporter svx2hto now is
       little use these days).
       
   The plan is to pull the existing code apart, and write a replacement
   in C++, reusing the better ideas and some of the better parts of the
   code. We'll also suck in code from Aven, PotRot, and Chasm, and
   possibly from other places.
   
   I know some will argue for Java rather than C++. But we've had that
   argument before and it didn't achieve much so I don't want to have it
   again. But I will point out that we have a lot of C and C++ code we
   can reuse which we couldn't in Java. And I'll also note that those
   developers who've expressed an interest so far all favour C++.
   
   Mark Shinwell has devised a plug-in architecture that is simple and
   lightweight (typically one machine instruction overhead). This will
   allow other people to write extensions which can be supplied
   separately (in much the same way that you can download a third party
   plug-in for your web browser).
   
   The network reduction code will be reimplemented as a library, which
   makes it a lot more modular, and allows it to be used in other
   programs (provided they are released under the GPL).
   
   My plan is to store the survey data in a structured file format
   (possibly an XML-like packed binary structure), with a simple
   (non-branching) version control system providing a revision history
   and allowing any previous version of the data to be inspected or
   processed (very useful for a large survey project lasting many years).
   
   Data in other formats would be converted to this format during
   processing, so input filters for the native formats of Survex 1,
   Toporobot, Compass, etc could be written. Similarly exchange formats
   such as HTO, SEF, CDI, etc could be just read in without an explicit
   import operation.
   
   This new format would also store a textual representation of the
   survey data, which could be used by the GUI data entry editor to
   preserve formatting of entered data (so if you enter 3.0 you later see
   3.0, not 3 or 3.00). It could also be used to produce a text file for
   external editing.
   
   The current prefix hierarchy will be replaced with a more structured
   one - keeping the flexibility where it's actually needed, but tagging
   levels as "country", "area", "system", "cave", etc.
   
   For ease of coding, I suggest using the C++ STL. It's not available
   everywhere yet, but is part of the ISO C++ standard and there's a
   portable implementation ([2]STLPort). C++ static object constructors
   seem to be a portability nightmare so I suggest we avoid using them.
   
   The time required should be much less than for Survex 1.0. We have a
   good idea of what we want to achieve as we've already written Survex
   1.0. There's plenty of code we can reuse or use for inspiration.
   Instead of just me coding with some help from Wookey, we're likely to
   have a handful of developers, and the plug-in architecture should
   allow us to avoid tripping over each other too much. Survex was my
   first C program, so a lot of time was initally spent learning C. And
   lastly C++ is higher level so coding time is more productive.
   
   It becomes a little more hazy from here on. We need to decide on a GUI
   toolkit to use. Gtk-- is C++ and would give us support for Unix and MS
   Windows. There is a Mac port in progress (and a BeOS port too), but I
   don't know of any plans to port it to palmtops.
   
   Another option is to wrapper the toolkit we use to allow other to be
   used, but that tends to result in "lowest common denominator"
   interfaces which isn't good.
   
   Palmtops tend to have smaller screens, so GUI modules designed for a
   larger screen size may need adjusting, but modern models are much
   better - Psion series 5 is 640x240 (same width as "real" VGA but half
   as high); Psion series 7 is 640x480 ("real" VGA).
   
   Whichever approach we take, we're unlikely to have GUI versions for
   MS-DOS or RISC OS, but command line versions are still possible.

References

   1. http://www.chaos.org.uk/cucc/expo/piclinks/phut1.htm
   2. http://www.stlport.org/