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

Re: Alt photo blog



Hi Ryuji,

I had a very painful experience last year with a virtual
private server company. The lesson is that, avoid cheap
service, and don't put all faith in any one company, even the
high-end server companies.
I've had an experience very similar to yours. I've since learned to always, always keep an off-site backup. This shouldn't be a problem.


Therefore, it is probably best for this parallel system to be
simple to use and email-based from the poster's view. That is,
the new parallel system should accept email submissions,
extract the attachments, and present them with the text body
on a web page.
Agreed. This was part of my motivation for suggesting a CMS solution, as it could accept both email submissions and posting directly through the website.


One problem here is authentication. I oppose unauthenticated
system because it is very easy to be flooded with spams. One
solution is to use the From header line of the email (e.g.,
all list member are allowed), and another solution is to
require a password in the Subject line or somewhere in the
email, change the password periodically and post the latest
password to the list.
Authentication is a very tricky issue for a list that's publicly available. If I post a password to the list, it gets cached by Google and the like and can be seen by anyone. 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. I'm not too keen on either of those, but at this point using a password in the subject line seems like the best solution to minimize spam, but I'm certainly open to suggestions.


In making such a system, the data format should be designed to
make it portable, that is, not dependent on a particular
server and can be copied over to another computer (Linux, Mac
or whatever) and still read easily. Although I do not see a
mature implementation of this yet, when one becomes available,
a CMS based on SQLite rather than client-server model based
database system is preferred. I know several CMS and photo
gallery platforms are currently undergoing this expansion to
work with sqlite, and so using such a system may make the
database conversion very easy in the near future.
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. 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.


I'll be putting some thought into this over the next week or so to figure out how to make this as user-friendly and archival as possible. I welcome any input anyone may have, on or off list.



Camden Hardy
camden[at]camdenhardy[dot]com
http://www.camdenhardy.com