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