FlickOff: Escaping the Clutches of Web 2.0
By Ben Okopnik
The Trap
Some months ago, while reading a Web site that contained suggestions for "streamlining your life", I signed up with Flickr.com, so I could have the photos from my cameraphone immediately posted to the Web. There were a number of benefits to doing so: I could photograph the label of a good brand of socks (or beans) that I didn't want to buy right then but wouldn't be able to remember when I did want them; I could snap a pic of something I wanted to research later without filling up my phone's memory - in short, I would now have a visual "memo pad" in addition to the written one that I keep around. I did chafe a bit under the restrictions of having to do this via a third party (Flickr) whose interests weren't exactly aligned with my own: as the price of this "free" service, I had to stare at the advertisements that, more and more, infested their pages; I had to make my way through their clunky, Java-scripted interface, which often created problems over my occasionally-slow connection; and, perhaps most annoying of all, I had to put up with their subtle-but-pervasive nagging, a feeling of being a cheapskate unless I bought their "premium" service. Hell, I was only using one of their features, and wasn't interested in anything else they had to offer! However, the overall convenience (slightly) outweighed the pain - so I stuck with it.
The Last Straw
Then, Yahoo bought Flickr - and added their password-and-nag system on top of the one already in place. That, I decided, was that. Enough, and Just Too Damned Much, in fact. I also recalled a conversation that Rick Moen and I had here, in LG's Answer Gang.
Every time I decline to use some third-party, usually proprietary service that I can reasonably do with Linux and open source on my own systems, instead, I am protecting and promoting the perception by onlookers that Linux and open source are the right solution -- not to mention improving my own competence. Internet services are supposed to be the Linux community's core competency: What sort of message does it send to go moving our affairs onto other people's third-party services as a convenience, in an area where we're supposed to be the leaders? -- Rick Moen
Rick had it exactly right. I gritted my teeth, set my shoulders, and growled... in short, I did all those things that a hero does in a movie before taking on the Bad Guys, blowing up a few buildings in slow motion, and Getting the Girl. I mean, if you're going to set out to do something this important, you might as well do it right - right? :) It seemed a little excessive for a programming project, but sometimes, you just need that little bit of extra motivation.
The Daring Escape
Cheating Checking Freshmeat and SourceForge didn't bring
any positive results, so I decided to create my own "image upload" system,
one that was more suited to my needs. I'd been using a piece of
photo-gallery software called "LiveFrame" to arrange and display my photos;
it was a bit old, and the author had moved on to other things, but I liked
the way it worked. Most of all, I liked its transparency in configuration
and operation: the images were all kept in subdirectories named after a
given category, the image headers and descriptions were listed in a single
per-category configuration file, and the gallery program itself was written
in my favorite language, Perl. Anything I didn't like, I could easily
tweak - and since I was going to use Perl to write this new app,
integrating the two might become an eventual goal.
I went through the LiveFrame code to make sure that everything worked OK and fixed a few minor bits; then, I settled down to writing my program, which I decided to call FlickOff. The interesting part was not so much the program itself - although that took a bit of work - but the network-interactive nature of the process: I decided to change not only where the images went, but how they were handled as well. E.g., since cameraphones aren't really professional photo apparatus, there'd be a number of times when I'd want to edit the image before sending it up to the Web. Some of the images would be private (I hacked LiveFrame to create categories that were invisible unless you knew their names.) In short, the process now looked like this:
Step 1: Take pic using cameraphone; add a subject line; email to self Step 2 (automated): When the email arrives at my laptop, anything from my phone's address is intercepted and sent to FlickOff. The subject line is parsed to determine the appropriate gallery - anything without one is sent to the 'unsorted' gallery; otherwise, the first word is the gallery name and the rest of the line is the image description. The local copy of LiveFrame then receives the properly-resized images and the description info is added to the config file. Step 3: I vet/adjust/process the images and the descriptions as desired, then run a script to synchronize the local LiveFrame repository with the "remote" (Web-based) installation, which makes the images available to the world.
In short, I've replicated the functionality that I wanted, got rid of the annoyances, and am continuing to refine the process as time goes on. At this point, I feel like FlickOff is nicely stable and useful to anyone else who'd like this kind of a system, so here's the setup procedure:
- Install LiveFrame and the image toolkit on your local machine. You can get the original version of LiveFrame from https://www.liveframe.org/, but I strongly suggest going with my (heavily tweaked) version from here - FlickOff is optimized to work with the features I've added. E.g., the images can now have full descriptions as well as titles; just add another separator character (described in the "config" file) and follow it with a description on the same line.
- Install LiveFrame on your Web server, and configure both locations appropriately (the configuration section at the top of the script is pretty self-explanatory.)
- Install the "flickoff" program somewhere within your $PATH; configure the three lines near the top of the script to point to your "reject" directory (i.e., any images that fail to be processed for whatever reason will be saved there so you can decide what to do with them; '~/flickoff/reject/' seems like a reasonable option), your "gallery" directory (top of the LiveFrame gallery hierarchy; e.g., if LiveFrame is installed in /var/www/lf, then this should be /var/www/lf/galleries), and your log file location (FlickOff saves step-by-step processing info here, so if you have any problems, you'll know what happened; '~/flickoff/log' seems sensible.) Don't forget to create the above directories if necessary.
- Modify your ~/.procmailrc to process the email from your phone by
adding the following:
# FlickOff SUBJ=`formail -x"Subject: "` ### Uncomment this stanza to save the raw emails # :0 c # * From: YOUR_PHONE_NUMBER@YOUR_PHONE_ISP # ${HOME}/Mail/photos :0 * From: YOUR_PHONE_NUMBER@YOUR_PHONE_ISP | /usr/local/bin/flickoff "$SUBJ"
The last stanza pipes your email to "flickoff" for processing. - Test it out, and enjoy!
Conclusion
Note that FlickOff was only tested with T-Mobile and Cingular/AT&T phones; if you have a problem with your particular setup, don't hesitate to e-mail me with the details (please make sure to include the photo-message that made it fail) and I'll do my best to adapt FlickOff to handle those as well. Happy Linuxing to all!
Talkback: Discuss this article with The Answer Gang
Ben is the Editor-in-Chief for Linux Gazette and a member of The Answer Gang.
Ben was born in Moscow, Russia in 1962. He became interested in electricity at the tender age of six, promptly demonstrated it by sticking a fork into a socket and starting a fire, and has been falling down technological mineshafts ever since. He has been working with computers since the Elder Days, when they had to be built by soldering parts onto printed circuit boards and programs had to fit into 4k of memory. He would gladly pay good money to any psychologist who can cure him of the recurrent nightmares.
His subsequent experiences include creating software in nearly a dozen languages, network and database maintenance during the approach of a hurricane, and writing articles for publications ranging from sailing magazines to technological journals. After a seven-year Atlantic/Caribbean cruise under sail and passages up and down the East coast of the US, he is currently anchored in St. Augustine, Florida. He works as a technical instructor for Sun Microsystems and a private Open Source consultant/Web developer. His current set of hobbies includes flying, yoga, martial arts, motorcycles, writing, and Roman history; his Palm Pilot is crammed full of alarms, many of which contain exclamation points.
He has been working with Linux since 1997, and credits it with his complete loss of interest in waging nuclear warfare on parts of the Pacific Northwest.