[ale] Wandering into the OT tar pit

[Mills, John M.]

Christopher - 

-----Original Message-----
From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
To: ale at ale.org
Christopher Fowler
Sent: Monday, March 13, 2006 9:17 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] Wandering into the OT tar pit (was RE: Wanted:trivial
minicom-type function)

On Mon, 2006-03-13 at 13:33 -0500, Mills, John M. wrote:

> I've had a couple of cases where I straightened up a design as part of
> implementing one or a series of customer requests in a previously
> "standard" product. Another occasion is handing the mess off to a
> hapless colleague who is better off to re-do than to fix the ^&%(!!.
> (_NEVER_ with _my_ work, of course ... &8-)
> 

CF> We've got some code that is a _mess_.  It all started with the same
CF> statement that started this thread.  "If just need this feature and
I'll
CF> clean it up later...".  Now we've got working code but a mess.  It
is
CF> even so bad as there is no standard among the apps as to how they
handle
CF> data.  One may use strcat() to append to a string while one will
build
CF> the whole string with snprintf().  

CF> Just tonight I added another module in the code and simply just
copied
CF> what was there.  There are no naming conventions either.  

We probably all have favorite 'war stories' about projects gone wrong. I
keep telling myself, "Design first, code later" but I am too easily
tempted to just start typing.

Legacy code with no documentation is a nightmare of "push it down here
and it comes right back up over there!"

CF> One problem I experienced in the past that was a bad idea is binary
only
CF> config.  We had many devices in the past use this method. It was
CF> required on those devices with slow processors, anemic flash, and
little
CF> memory.  On this device we had a bit more room.  The problem with
binary
CF> config is that any additions or subtractions meant the previous
version
CF> of config was no good.  Very bad.  On that device we are at rev 7
and I
CF> do not intend to see rev 8 :).  The reason why I brought up Mini-XML
is
CF> that I now use it on the new device to store the config in XML
format
CF> when not in use.  

CF> XML -> struct {} -> Shared Memory.
CF> save: Shared Memory -> XML -> Compression -> Encryption -> Flash. 

Thanks for the lead to 'mxml': I've been looking for a small-scale tool
to process XML configs. I'll build it and check it out.

 - Mills