next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects
Index of Subjects
On Aug 14, 4:48pm, Mica Currie wrote:
}
} > Many of the people pushing the notion of sql for this application
} > have missed the picture.... namedb is actually a _very_ elegant
} > solution... it allows a users complete history to be stored and
} > accessed in very easy and straightforward fashion.
} >
} > Storing information is simplicity itself, retrieving the current
} > value for a data set is very straightforward... and the text format
} > lends itself to extending the data structures and debugging
} > routines... of all the people arguing against it Michael Smith is
} > probably the only one who's taken the time to figure it out.
}
} I think you have hit the nail exactly on the head... Most people haven't
} taken the time to figure it out.. mostly because there are a lot of us who
} don't enjoy tracing through csuites "elegant solutions" Perhaps I'd feel
Hmm... It would probably be easier to understand namedb if there
was a single interface to it. It would also be easier to maintain and
debug; not to mention, less likely to have bugs.
} differently if the system was documented well so that when things went
} wrong you could at least find out what something inside the code is
} supposed to do, what it relys on and what assumptions it makes.
I would agree that the documentation on the code is somewhat
lacking. There are probably several reasons for this. The biggest one
being that a lot of CSuite work is done by volunteers, or people who's
primary job isn't working on CSuite. Many programmers don't find
writing documentation to be very "sexy" or fun, and volunteers tend to
work on what they like. Also, this type of programming tends to lead
to severe time constraints. I.e. the next revision of CSuite must be
pushed out the door in a couple of months at the latest due to Y2K.
This means that working on code is going to have a much higher priority
then working on documentation.
That said, if somebody was to volunteer to write the needed
documentation, I'm pretty sure arrangements could be made to include it
with CSuite or put it on the website. There is some documentation
located at: http://www.chebucto.ns.ca/CSuite/ . I don't know how up
to date or complete it is, but it should be a good start. This
information should probably be moved to http://www.csuite.ns.ca/ . A
fair amount of documentation is also contained in the CVS commit logs,
but that's not public at the moment. And, of course, you can ask
questions here and on csuite-tech (csuite-tech would probably be more
appropriate for most questions).
} As for easy to figure out what the current settings or data is in
} csuite... I'll point you to csuites love of variable redefinitions...
} Instead of replacing values during an automated configuration sequence it
} appends them to the end of the file or overiding that setting somewhere
} else...
This does make it easy to update things. The configuration stuff
could probably be changed to overwrite variables instead, but that
would make it more complex. Suggestions for changes and/or patches
will certainly be considered. A lot of the recent changes to Lynx were
contributed by Blue Sky Community Network.
} Two cases are brought to mind specifically in the vars file... The first
} involved a poor pathname which resulted from a configuration change...
} When the file was hand edited The first occurance of the variable was
} altered instead of the last... Because it made no sense to have multiple
} definitions of the same static variable no further configuration was
} done... Csuite of course completley ignored this first variable in favor
} of the final definition further on down the file... Csuite is riddled with
} this sort of counter intuitive programming style.
This is the fault of the person making the change. When one
modifies a configuration file by hand, they should always read the
whole thing and make sure they understand it and the consequences of
the changes before doing so.
} The second instance is the CS_GROUP_ID and CS_GID variables (this is from
} memory so the exact variables may be wrong) Csuite in all it's wisdom uses
} multiple variables to hold the same information. Scripts use a mixture of
} the variables so they appear randomly intermixed even within the same
} script.
The variables in question are CS_USERGROUP and CS_UGID. The first
is the group name, and the second is the group id. Although they both
reference the same thing, they may both be needed. Without doing a
complete examination of their usage, I can't really comment on them.
}-- End of excerpt from Mica Currie
next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects