Thanks Taco!
On Mar 10, 2009, at 11:24 am, Taco Scargo wrote:
> I will power up one of my old BTOS servers which contains a copy of
> the CVS
> tree, maybe it contains the original documentation as well, although
> I doubt
> it, as that was marketing handling that.
>
> Regards,
>
> Taco
>
> On Tue, 10 Mar 2009 14:43:19 +0100, Michael Stauber wrote
>> Hi Greg,
>>
>>> This is probably the route I'll end up taking, but I was hoping
>>> for a
>>> solid (ha!) starting point. My fear is that if I borrow someone
>>> else's
>>> mistakes, I might be compounding the problem. We'll see what I get.
>>
>> Yeah, start with something small. Like creating an UI page with a
>> single input field (may that be a checkbox or a form field), which
>> does something on the system level. And may that just be creating a
>> temporary file with "hello world" in it. Create the schema for your
>> database object, a Perl handler that writes the tempfile and a
>> config file that triggers the handler whenever the database object
>> is updated. Then finally the UI page(s) for it.
>>
>> A good starting point to "borrow" the code for that could be base-
>> apache or base-ftp for example.
>>
>> As for borrowing "bad" code ... <lol>. Yeah, after a few years of
>> working the Sausalito code I think I've seen it all. There are
>> plenty of way of how to do things - some more efficient than others.
>> And some of the original code really shows if it was done by a
>> master or an apprentice. Sometimes when I look at some of the
>> handlers or Perl modules that have Will DeHaan's handwriting on them,
>> then I still have to tip my hat. Some of that code is utterly
>> splendid.
>>
>> Example: There is a function in one of the original Cobalt Perl
>> modules called "hash_write". It deals with writing "stuff" to files.
>> Often when you update a config file you have to jump through burning
>> loops to make sure that you add all the relevant info in the correct
>> syntax, without putting the same line twice. And it would also be
>> nice if manual addition to that config file weren't overwritten
>> either. Re-writing the entire config file from top to bottom ain't
>> the most stylish way to do this - of course.
>>
>> Now here it really shows how ill Cobalt documented their own stuff,
>> because this brilliant "hash_write" function is used like only once
>> or twice in the entire code. For all other transactions where they
>> write to config files they use sub-standard methods, sometimes just
>> re-creating the entire file with popen() and fputs().
>>
>> Why is "hash_write" so great? Well, it works like this: You put
>> everything that you want to add or change in your config file into a
>> Perl Hash. Then you call the function and pass the Hash to it,
>> together with the delimiter that separates switch name and value,
>> plus you specify the character that indicates that the line is a
>> comment (typically "#" ). Oh, and of course the file name of the
>> config file to edit.
>>
>> The function will then "walk" through that config file, where it
>> replaces just the lines you want to change. If you passed a switch
>> that it didn't find, it'll (optionally) add it. And it won't touch
>> any other line in that config file - so manual changes to other
>> sections of said file will be retained. Or if the config file is
>> missing, it'll simply create it with whatever info you had in your
>> Hash.
>>
>> The entire function is just a few lines of code and calling it is a
>> simple one liner. But it saves a hell of a lot of time and hassles.
>>
>>> I seriously wonder if there was a Chapter 1-16 to go with the #17 I
>>> have (and possibly 18-26...). I wish there was one of the original
>>> engineers who also happened to be an information pack-rat (like me)
>>> who happened to keep a copy of all this stuff, for posterity.
>>
>> Yeah, I'd love to take a look at those as well. :o/
>>
>> --
>> With best regards,
>>
>> Michael Stauber
>
>
>