On Sun, Sep 11, 2011 at 2:22 PM, Richard Gaskin wrote:
> Roger Eller wrote:
>> > ...so for protecting the initial md5digest, I might store it in
>> > a database rather than a file. That could possibly make retrieval
> > of that code more efficient, and also add a protective layer.
>> If someone has sufficient access to modify files on your server, that may
> include your database as well.
>> Databases are handy for working with very large data stores, esp. where you
> need relationality but for simple things like a checksum value for a file,
> Mark Weider's suggestion is probably the simplest and most efficient, to
> just store a checksum file with the actual file,
>> With a database your client talks to Apache, Apache loads your CGI, your
> CGI connects to the DB, then it submits the request through the the driver
> where the DB traverses its hash table to find the record, returns that data
> back through the driver interface to your CGI, then your CGI hands it back
> to Apache for delivery to the client.
>> As a file, Apache just gets the file itself and returns its data to the
> client.
>> On some file systems you may be able to measure a performance difference if
> your directory has more than 32l files in it, but even then it's probably
> not as much as the overhead of connecting to a DB.
>> --
> Richard Gaskin
> Fourth World
> LiveCode training and consulting: http://www.fourthworld.com> Webzine for LiveCode developers: http://www.LiveCodeJournal.com> LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
Richard, would you have the same reservations about database usage overhead
if a standalone or revlet were used as the client? There are over 100,000
files pre-existing, so an initial creation of a server-side md5digest for
every file would be a challenge in itself. How about a standalone which
lives on the server-side (always running - kinda cgi-like) which accepts
requests for a files md5digest and returns that string to the client
standalone/revlet before starting the download. This is LAN based, so the
clients are few and the scope is limited, therefore malicious activity isn't
expected. But it never is, is it? ;)
˜Roger