On November 30, 2000 at 19:36, Gerry Hickman wrote:
Let me count the ways I like static HTML files.
* simplicity
* simplicity
Uh? I'd say it's the other way round. Maybe we should run our e-commerce
systems using comma delimited text files and static JPEGs and use FTP to
upload hundreds of static pages every time we want to update product
information? Maybe we should upload a whole page of prices every time a
single price changes? Maybe we should use hundreds of font tags and
color tags in our HTML instead of style sheets?
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. A dynamic
system requires the installation of a database, which from my
observations from many users, prefer not too muck with. The file
system is already installed on your system.
Depending on your goals, MHonArc is incredibly simple or can be
somewhat difficult.
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. 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.
Are we really talking "simplicity", or are we talking "short
sightedness"?
Unfair statement since you fail to view the issue from different
perspectives.
* their benefit from internet caching infrastructure
I'm not sure what this means.
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.
* computational cheapness of serving them (disk is cheaper than CPU)
But server side code that returns a small result set may actually be
more efficient for both the server and the client.
This statement does not invalidate the original statement. Both
statements have merit, but can be wrong depending on the circumstance.
* manipulability with many, many tools
Uh? So what exactly can you do with your MHonArc message files with
these tools that you couldn't do with a simple update query in SQL
server?
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.
* benefit from OS level improvements
I don't know what you mean here.
File systems have existed for a long time and are quite reliable and
trivial to backup. Also, with many OS's, file system operations are
cached, where the cache size can be adjusted. There are also reliable
OS checks for fast and efficient file access. It is faster to retrieve
the contents of a file off the file system than the same content from a
database management system.
Some people, like me, despise databases and like static files a lot.
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.
As I like to say: Different tools for different jobs, and not one
tool is applicable, or appropriate, for all jobs.
--ewh
