sweetjesus26

This blog doesn't get used any more.

Please see my tumblr.

Format a Python datetime as a string according to RFC 2822 section 3.3 respecting timezone. Adapted from Python's email.utils.formatdate. As a handy companion, dateutil.parser.parse works quite nicely for parsing them.

def formatrfc2822datetime(value=None, usegmt=False):
    """Returns a date string as specified by RFC 2822 section 3.3., e.g.:
        
    Fri, 09 Nov 2001 01:08:47 +0900
        
    Optional value may be a datetime value. Timezone is respected.
    """
    # Note: we cannot use strftime() because that honors the locale and RFC
    # 2822 requires that day and month names be the English abbreviations.
    if value is None:
        value = datetime.datetime.today()
    if usegmt:
        # Convert to UTC/GMT
        value = value - value.utcoffset()
        zone = 'GMT'
    else:
        offset = value.utcoffset().seconds / 60
        # RFC 2822 3.3.: The form "+0000" SHOULD be used to indicate a
        # time zone at Universal Time.
        zone = '%s%02d%02d' % (offset < 0 and '-' or '+', offset // 60, offset % 60)
    return '%s, %02d %s %04d %02d:%02d:%02d %s' % (
        ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'][value.date().weekday()],
        value.day,
        ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',
         'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'][value.month - 1],
        value.year, value.hour, value.minute, value.second, zone)

On Saturday arinellen, tribaldemon, Paige and I went op shopping and I bought this cute pie dish with a a recipe for cherry pie on the bottom. "Mmm, this pie is delicious, can I have the recipe?" "Sure, just eat the rest!"

Naturally Paige and I had to make peach pie!

Pastry:

• 3 cups self-raising flour
• 3 tablespoons sugar
• 250g butter, cold, chopped
• 2 eggs, lightly beaten

Place the self-raising flour in a bowl. Create a well and fill with eggs and butter. Rub flour into the eggs/butter trying to touch only flour. The pastry should attain a golden colour and flaky texture. Line a pie dish (ours was 9") with about half of the pastry moderately thickly.

Pie filling:

• 1 large tin peaches in juice
• 1 cup brown sugar
• 2 tablespoons butter
• 2 tablespoons cornflour
• ½ teaspoon nutmeg
• ½ teaspoon cinnamon
• ½ teaspoon vanilla extract

Strain peaches, keeping ½ cup of juice. Combine juice, sugar, butter, cornflour, nutmeg, cinnamon and vanilla extract. Place peaches in pie dish and pour over just enough liquid to submerge. Cover with pastry, sealing edges with a fork. We had a bit of pastry left over (it's so tasty >.>).

Bake for around 20 minutes in a hot (250°C) oven, or until golden brown.

Pics coming soon! (Pie is half-eaten now, though.)

class GoogleUsers(object):
    """ Pythonic interface to Google Provisioning API. """
    ...
    def __delitem__(self, key):
        delete_key = 'delete%d%d' % (time.time(), os.getpid())
        self.gdata_api.RenameUser(key, delete_key)
        self.gdata_api.DeleteUser(delete_key)
    ...

In case anyone else has the misfortune of being stuck on a Debian Etch box with Python 2.5 and finds themselves needing Python-LDAP:

Installing the latest version of Python-LDAP 2.3.x doesn't work. It requires OpenLDAP >= 2.3. Installing an old version of Python-LDAP using Python 2.5 against the OpenLDAP ~= 2.1 libraries available in Etch gave me no end of segfaults and weird issues and going back to Python 2.4 wasn't an option.

OpenLDAP 2.3 has been backported by the Debian security team, thankfully. Problem: they didn't create a development package. Solution: I grabbed the source package and fiddled with Python LDAP's setup.cfg. Put the source package somewhere and apply the Debian patch manually. Change the [_ldap] section of Python-LDAP's setup.cfg to something like:

[_ldap]
extra_objects = /usr/lib/libldap_r-2.3.so.0 /usr/lib/liblber-2.3.so.0
extra_compile_args = 
libs = sasl2 ssl crypto
library_dirs = /usr/lib
include_dirs = /root/openldap-2.3.30/include /usr/include/sasl

Now easy_install the directory and you're done! Not very Debian, but it works.

Thinking about webmail has got me thinking about mail at large.

From what I've read/seen most people doing mail open source use something like Dovecot with Large Storage™. What about when that needs scaling? A popular solution seems to be using a combination of a few approaches to horizontal scaling:

• Partitioning mailboxes using the first letter (or similar) and:
• telling each user which server to use; or
• using an IMAP Proxy like Perdition (client – [imap/pop3] → server 1 – [imap/pop3] → {[a-j]* → server 2, [k-z]* → server 3} or similar).
• Use a shared file storage backend like NFS, GFS, or similar with multiple transport nodes (client – [imap/pop3] → server 1, 2, 3 – [nfs] → server 4 or similar)
• Use harder/better/stronger/faster hardware.

With the advent of cloud computing how can this be done better? What about a cloud of SMTP/LMTP/IMAP/POP3 servers accessing an S3 like service for mail storage? (Hello Eucalyptus!) One could use MapReduce (using Hadoop? with Hive?) to maintain the mailboxes and create an FTS index. DBMail has an interesting idea but misguided implementation, imho. This would be true open-source Gmail!

I don't think it would be too difficult to create a new mail storage backend for Dovecot and use it for the actual mail transport. (aside: There's currently an experimental backend for SQL mail storage.) It's a pretty good base for any new functionality just by writing new plugins. Putting these atop some lean Ubuntu VMs on Eucalyptus gives massive scalability and HA, and backing onto an S3 w/ MapReduce gives fast, scalable, indexed and HA storage.

Is there any open-source interest in this? Anyone who might get excited with me?

In case you didn't know, I'm in Rome. See my Twitter for more details.