So dmedia has a very abstract concept of a "store". A store can be the native dmedia FileStore somewhere on the local file system, or it can be a remote service like S3 or whatever.
So we should of course support OpenStack Swift: https://launchpad.net/swift
Currently S3 (via boto) is the only proper remote store supported (both upload and download). You can see the S3 backend plugin here:
http://bazaar.launchpad.net/~dmedia/dmedia/trunk/view/head:/dmedia/backends/s3.py#L97
The base class may not be generic enough yet, may not have the right abstractions:
http://bazaar.launchpad.net/~dmedia/dmedia/trunk/view/head:/dmedia/transfers.py#L243
So this bug may take some slight changes to the TransferBackend base class.
Also see the related bug to add a transfer backend for the UbuntuOne Files API:
https://bugs.launchpad.net/dmedia/+bug/830684
Marking this as Wont Fix.
The native Dmedia upload protocol is much easier to work with, and offers class-leading resumable uploads (because of great incremental verification).
So I really think the native Dmedia protocol makes the best entry point into the cloud, rather than trying to directly talk to the cloud platform object store (be it Swift, S3, whatever).
Note that I'm still very committed to people being able to use Dmedia with their own cloud account (Rackspace, AWS, etc), and I would accept a patch from someone for this. But for now, I'm personally going to focus on perfecting the native Dmedia stuffs, then work on abstracting things enough to support directly uploading to other object stores.