In my recent post entitled, Faetus v0.5 released!, I described how and why I built a Python-based FTP server that reads and writes to Amazon S3. This project was born out of necessity because I am using a 3rd-party file management application (which didn't understand the S3 API) but needed the files to end up on S3. The system did talk FTP, so I wrote an FTP server that does just that.

As it turns out, the file manager DOES now support the S3 API. Therefore my immediate need for an intermediary FTP interface is gone. While I think it is still a very cool idea, I no longer have an urgent need for it. I will continue to fix some of the major bugs with it, most of my tinkering will cease. Please let me know if you are interested in using Faetus and I'm happy to offer continued support.

Faetus is an FTP server that translates FTP commands into Amazon S3 API calls providing an FTP interface on top of Amazon S3 storage.

This project came out of a specific need I have at PBS. I need to put files on Amazon S3 storage, but the 3rd-party file management system doesn't know how to speak to S3's APIs. What the system does understand is FTP. So I decided to write an FTP server that utilizes S3 storage as opposed to local filesystems.

The server is based on pyftpdlib, a Python library that implements most, if not the full RFC spec for. Especially nice is the fact that the the library implements the filesystem layer in an abstract fashion. I basically needed to replace all the filesystem calls with S3 API calls. I used boto to handle all the S3 API calls and I quickly had a working prototype.

After playing with my prototype for a few hours, I stumbled upon Chmouel's ftp-cloudfs... who basically did the exact thing I had just done, but for Rackspace CloudFiles. For consistency's sake, I rolled my code back, forked ftp-cloudfs, gave the project a questionable new name, and added my S3 code back in. La voila!

• Faetus project page
• Source code on GitHub

Google released GoogleCL last Friday they describe as "Command line tools for the Google Data APIs". I took a few minutes to play with it today and an awed by the possibilities it opens up. Yes, APIs have existed for all these services, so in theory, it's nothing new... But really, who wants to write command-line wrappers for the APIs, or manage all the different 3rd party packages for doing so.

It's basically a bunch of Python scripts that are all imported into one executable file called "google". All the API calls are full abstracted allowing you do run commands like:

$ google contact list
$ google calendar add "Get up at 5:30am Thursday"

GoogleCL currently supports Blogger, Calendar, Contacts, Docs, Picasa, YouTube... though I'm sure others will be added shortly.

Installing is pretty much a piece of cake. All you really need is a modern version of the gdata library (mine was outdated) and the googlecl package itself.

$ pip install gdata googlecl
$ pip install 

I see some serious life automation happening in the near future.

Source code available at GitHub:
http://github.com/tomatohater/django-openlike

Release notes (v0.1):

# django-openlike

Django template tag for easily implementing and extending OpenLike protocol.
See http://www.openlike.org/ for more info.

FEATURES:
- Templatetags for displaying OpenLike widget

USAGE:
- Basic: {% openlike %}
- Less basic: {% openlike "http://domain.com/" "Page title" %}

TODO:
- Documentation.
- Add support for extended sources.
- Configuration via Django admin

AUTHOR'S NOTE:
This app is most definitely overkill given the simplicy of OpenLike and the
ease of pure JavaScript implementation. But it was a fun project to fully
support a third-party service in Django.

This is my deck from RightScale MeetUp 2010 before it was incorporated into RightScale's template. The full MeetUp presentation is up on RightScale's website.

At the MeetUp, I met a ton of really smart people with interesting problems to solve... many with the same problems I'm working on as well.