Hi Earl,
* simplicity
* simplicity
Uh? I'd say it's the other way round.
The concept of "simplicity" will vary depending on your point of view.
For example, MHonArc as it is today is simplier than a dynamic system
sense no other software tools (excluding Perl) is required.
Yes, a good point and I imagine it would be tricky to support all the
database variants across a range of platforms.
A dynamic
system requires the installation of a database, which from my
observations from many users, prefer not too muck with.
I was assuming most most people running web servers these days would
also be running a database, but I guess it's hard to tell without a user
poll or something.
Have you considered how many times the string "<html><head ..." resides
in your thousands of static HTML pages adding useless bulk both in terms
of storeage and bandwidth?
Bandwidth is bogus since a dynamic system will still send "<html><head..."
for the pages it sends.
Yes, but that info can be held in _one_ script file - it does not need
to exist in every file on the hard disk. It also makes it a snap to
change page layout elements on the fly, or add new cool features. Of
course most of this can be done using "rc" files today, but this will
still end up in static pages.
With the active scripting idea you could render pages in a special way
based on criteria in the query. You could also return non-contiguous
result sets such as "all messages from 1998 containing attachments". You
could then have a button that would delete all those messages from the
archive by running a delete query on the result set. None of this would
require MHonArc. MHonArc would only be needed to stream the messages
into the DB in the first place it would then by up to the user to decide
what they wish to do with it.
Storage is valid, but may be negligable depending
on the block size of the file system, the file size itself, and if
(gzip) compression is used. BTW, databases add there own storage
overhead.
Agreed, but I think having it all in one big file with a replication
script for backup is much easier than thousands of static files... You
can also run some pretty powerful queries, which I feel would more than
compensate for the "tools" mentioned below for the parsing static files.
Are we really talking "simplicity", or are we talking "short
sightedness"?
Unfair statement since you fail to view the issue from different
perspectives.
Agreed :)
Since we are dealing with static files, typically client-based caching
can be leveraged. Dynamic pages typically are not cachable unless
you explicitly handle it.
Right, I understand now, but why would anyone want old e-mail messages
to be cached in their browsers? Surely these archives are used more for
quick look-ups and references, not be read over and over again by the
same visitor?
* manipulability with many, many tools
Full text search indexing. Many indexing tools work best with regular
files on not with data in a database, especially the free ones. Basically
any tools that works with regular files can be applied.
Well, again I'd personally rather have the power of database tools than
text file parsers.
But that's sometimes more to do with living in the dark ages than a
real-world reason.
An uncalled for statement. I guess you never work with regular files
at all but just interact with a database for everything. BTW, in
case you do not know, a file system is a type of database. I guess
those C programmers live in the dark ages because they do program
in Perl or Java.
I have nothing against the C language. I've been trying to avoid Java,
but it does seem to have a valid place in the new "client-less" software
environment that's starting to arrive in mainstream business.
I still think my statement has relevance though. It's like when CSS and
DHTML first arrived everyone said it was just a "gimmick" and the old
standard HTML was what everyone should use. I guess some people will be
saying the same thing today about XML. It seems to me some of the
resistance to change is as much to do with ignorance as valid
reasoning...
As I like to say: Different tools for different jobs, and not one
tool is applicable, or appropriate, for all jobs.
Agreed.
--
Gerry Hickman (London UK)
