That's what I've been doing with this app for the last 10 years ;) It's
just that when you need document/image "portability," the file-system method
gets messy from a security standpoint.
Take synchronizing a sub-set of "internal" images and documents to a
least-privileged DMZ segment. Doing this from a file-system standpoint gets
complex when you do it securely - and besides, storing the image name/path
in the DB requires that I replicate both db data and file system data. If I
can replicate everything within a single, encrypted connection, that makes
things much easier.
But I totally agree with static content. All the static content will be
file based, as it should. And you actually sparked an idea as I write this--
which would be to securely replicate data to my destinations (my remote
facility and to different DMZ segments) but to then extract the data to the
filesystem where I can more granularly control access. That's not a bad
idea, actually. More complex from a development standpoint, but it nicely
addresses the "portability" issue while still taking advantage of strong
controls and performance. I'll have to think about that some more.
t
On 9/20/06 12:33 PM, "matthew patton" <pattonme@yahoo.com> spoketh to all:
what makes sense is to store the path to the image file in a database
and then shove that string into the generated HTML. that way the
browser and the static content webserver do what they are good at.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
