U of S | Mailing List Archive | alt-photo-process-l | Re: Alt photo blog

Re: Alt photo blog



From: Camden Hardy <camden@camdenhardy.com>
Subject: Re: Alt photo blog
Date: Thu, 19 Jun 2008 15:18:51 -0600

> If I post a password to the list, it gets cached by Google
> and the like and can be seen by anyone.

That's why I said to regenerate password and post it
periodically. If you re-generate a password every Sunday or
every 1st day of the month, the password should expire before
it gets widespread circulation. I mean the password for email
submission only. You should keep the u/p for web interface
more tightly as usual.

> If I authenticate based on who the email is coming from, I'd
> either need to maintain a duplicate copy of alt list
> members' addresses or get dynamic access to Gord's list.

People who do not post to the list have no use for this
parallel system. It is not unreasonable to use a list of
actual posters in the recent 2 months period, or recent 465
postings, or whatever.

Of course, there could be any number of authentication
methods, but this is always a tradeoff between accessibility
with average users. If you require PGP encrypted and signed
email for submission, how many would use the system?

> Most CMS systems use PHP/MySQL, which is very easy to backup
> and/or transfer to another server/format/etc., so that
> shouldn't be a problem if I go that route.

It is easy to dump mysql database, but if you keep the archive
in mysql dump format, those who wish to have a copy of the
archive and view on a local machine would require a mysql
installed. Sqlite would solve this problem without hurting the
server performance at all, as long a single server
implementation can manage the level of page views, which I am
not worried at all.

> The other option I've been thinking about is to create a
> very lightweight email-only system that handles file
> size/naming and responds with a link to the file in
> question.  If I do this MySQL will still be used to store
> the data.

Well, if you program in PHP (or anything commonly used), you
might want to know that Sqlite is a standard library and you
can use it very easily, without the overhead of interprocess
communication. I archive all my past emails using Sqlite and I
am very happy with the results. Good thing about Sqlite is
that the database is one file, and you access this through the
library functions. Backup can be done with one rsync script
and doesn't involve dumping mysql first. Another good thing
about Sqlite is that it doesn't use interprocess
communication, so that the response latency can be improved on
a server under some load. Data security is commonly mentioned
as one shortcommings of Sqlite, but if the contents is all
public, and if the purpose is to make this database more
accessible, I think this is actually a good thing. Another
shortcomming is that you can't distribute over multiple
servers like you can with mysql. I'm not worried about this at
all.

--
Ryuji Suzuki
"Strange how people who suffer together have stronger connections
than people who are most content." (Bob Dylan, Brownsville Girl, 1986)