gawk vs sql

From: jnemeth@victoria.tc.ca (John Nemeth)
Date: Thu, 14 Oct 1999 03:09:30 -0700
To: jwarnica@ns.sympatico.ca (Jeff Warnica), "Michael Smith" <michael@csuite.ns.ca>
Cc: "CCN Tech" <ccn-tech@chebucto.ns.ca>, <csuite-dev@chebucto.ns.ca>
Precedence: bulk
Return-Path: <csuite-dev-mml-owner@chebucto.ns.ca>

next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects

Index of Subjects
On Sep 1,  9:02pm, Jeff  Warnica wrote:

     I've been busy lately with various projects, so I haven't had a
lot of time to deal to deal with e-mail...

} I was planing on not continuing this discussion anymore since I realized I
} don't care..

     I thought about dropping this thread, but there are some
misconceptions in it that I wanted to clear up.

} But I do have to address this:
} 
} > } > } More complex? SQL would be far less complex, and more easily
} > } > expanded on.
} > } >
} > } >      A real database program is more complex to setup and
} > maintain then
} > } > a bunch of text files.
} > }
} > } I supose it depends on how you look at it. With a SQL database,
} > thats some
} > } one elses problem, to a programer it may as whell just be a magic box.
} >
} >      So, are text files.  We are talking about programmer's here, or
} > people taking on a programming role.  If you want to change things, you
} > have to figure out how to use the back-end regardless of what it is, or
} > the interface to it.  I really don't see the point of this statement.
} 
} I am quite aware of CSuite making a great effort to reinvent the wheel
} whenever possible, mucking around with other peoples code, putting things
} where they shouldn't go and the like, but you not actually thinking of

     This statement is utter nonsense.  I will address each of your
points seperately.

     First, CSuite makes a lot of use of programs commonly found on the
Net.  This is quite obvious, since at last count there are over 30
third party packages included with CSuite.  CSuite only writes what
can't be found elsewhere.

     What is wrong with "mucking around with other peoples code"?  It
is common practice to modify code that one finds on the Net to meet
their need.  Also, it isn't done just for fun.  Modifying code is done
for one of the following reasons:  integrating it with CSuite in order
to make a turnkey, easily installed, maintained, and supported system;
add internationalisation support (this was a requirement for Industry
Canada funding), security, fix bugs, and finally to add needed
functionality.  There may be some changes that aren't strictly
necessary.  These are being removed as they are found.

     The most common change is to add a single target to the Makefile
to get the package to install in the right place, followed by changes
to configuration files to make the package behave the way we need.  Of
course, the whole purpose of a configuration file is to customise the
operation of a package, so changes to them don't count.

     As noted, internationalisation support was a requirement for
Industry Canada funding.  Besides, it is a good idea, considering we
want CSuite to be usable around the world (in fact there is a project
currently in progress to get CSuite used in a non-English speaking
country).  Luckily over the last couple of years, a couple of the major
programs in CSuite (Lynx and PINE) have had internationalisation
support added by their respective maintainers, so we won't have to do
that again.  Although, depending on the languages we're interested in,
we may have to make up translation tables.

     Security on a system like one running CSuite is a lot different
from security on a general use computer, so sometimes we have to
modify a package for security reasons.  Quite often, this is just a
simple matter of making appropriate changes to a configuration file;
although, sometimes we do have to make minor tweaks to the code.

     Fixing bugs is rather obvious, not all code found on the Net is
bug free.  Sometimes this means upgrading to a newer version of a
package, sometimes it means backporting a fix if we can't upgrade for
some reason, and sometimes it means coming up with our own fix.

     Finally, a few packages are modified to add needed functionality.
The biggest example of this is Lynx.  Since Lynx is our user interface,
and our needs are pretty specific, I don't think we'll ever get away
from making modifications to it.  There are a handful of other cases as
well, but they are being reduced over time.

     In the past, some changes were made that weren't strictly
necessary.  As I said, these changes are being removed as they are
found, if for no other reason that they make upgrading the package more
difficult then need be.  If there are specific changes that you feel
are gratuitous feel free to point them out, and we'll see what can be
done.  I can't make any promises, since we are late in the development
cycle.

     CSuite goes to great effort not to put things where they don't
belong.  In a package like CSuite, which is designed to run on a number
of systems and is very large, everything it does should be contained
within its own area.  The only thing it modifies outside of its own
area, which are pretty much impossible to avoid, are replacing the
sendmail and rmail binaries, and adding/removing entries in the
password database and group file.  It would be wrong for CSuite to
willy-nilly muck around with whatever it wanted just to avoid keeping
the item in question inside its own area.  That would also produce a
system that is impossible to maintain and support.

} writing a SQL database backend are you?

     No.  As I said before, I have enough stuff to do right now,
without inventing make work projects.  So far, nobody has provided what
I would consider to be a convincing reason for totally rewriting the
backend account database (not to mention the problem of migrating
existing systems).

} Unfortunatly there are no pretty pictures, because the cache dosent cache
} those, but It wont matter because the Csuite philosiphy is to force everyone
} to use unusable tools, so you wouldnt beable to see them any way, but you

     This statement is nonsense.  The tools provided with CSuite are
quite usable.  They might not be as powerful as you would like, however
most people using CSuite wouldn't be able to use the more powerful
tools, so we have to stick the more userfriendly tools, such as PINE.
Your statement here obviously concerns the lack of a graphical
browser.  Many CSuite users can't use them.  As has been pointed out
here before, many users of a number of sites have said that they don't
want to lose text based access since their computers aren't powerful
enough to run modern graphical browsers and they don't have the funds
to upgrade them.

} should spend 5 minutes reading
} http://www.google.com/search?q=cache:1621214&dq=cache:themes.org/totd/guest/
} archive/jwz/ That interview has significantly changed my views of computers
} and the internet. Specificly:
} 
} "
} Operating systems matter deeply to
} programmers, but in the big picture,
} they're old news. It's all about the network,
[snip]

     I read the article.  I have to say that I disagree with most of
the things in it.  But, to address the point of operating systems, they
aren't a solved problem.  Although application programmers and users
shouldn't have to worry about them, somebody does.  A computer without
an operating system i