September 7th, 2007



I started the day with two telecons, both of which I think will become gigs. Then I went heads down reading yet another new REST API doc.

By mid afternoon, it had gotten really nice and sunny outside. At 3, I walked to the south end of the neighborhood, to adrienne_r's place. She needed someone to keep her focused while she put away huge pile of freshly washed clothes.

At 7, I went downtown, to the first Noonhat Happy Hour. It was an interesting and eclectic crowd.

I met the guy in charge of infractions at the municiple court (the guy who manages the org that takes your money for parking tickets), and helped him brainstorm out a solution to an awkward network security problem he had.

I met also two geeks, one with a great idea on using XMPP to help solve the distributed social graph problem, and the other newly moved to Seattle, with an idea for a startup. I gave them both my card, telling them to email me so I can send them links and email addresses to stuff and people they should know.

When I got done and overwhelmed there, I left, and realized I was downtown at almost 9pm on a Thursday, with open time. So I went to the Grind, I think for the 3rd time in a row. I spent the next 4 hours dancing and socializing.

There was a really cute couple who put on a great show. Watching with a friend, we decided that the couple had known each other for years. But chatting with them later, we learned that they had actually met at the Spot only last week. They just clicked really well.

After 1, when the Grind shut down and they threw eveyone out, a small group went to Denny's for bad food.

And then I came home and fell into bed...

Idea: Syncing IM buddylists and addressbooks

Adium for the Mac keeps its buddylists in sync with the Mac iCal database.

The Linux Desktops should do the same thing. It not even that hard.

Evolution, Thunderbird, Chandler, etc should can listen on DBUS for vCard events. Pidgin, and also the top few open source softphones, should can publish vCard events to the DBUS as you add buddies.

It can go the other way too...

What Skype should do with their Linux client

Well, what they really should do is open source it and/or publish their protocol, but barring that.

Rip the existing GUI off of it. Completely.

Instead make it a pure background daemon process, that uses system IPC, local sockets and/or DBUS. Receive dialing commands and configuration commands via a command socket. And do all its user multimedia via the now standard linux desktop multimedia framework, and/or dynamicly created local domain sockets. And publish "interesting" events over the DBUS.

That way people can write different and different kinds of UIs on it. Simple little command line tools, complex GUIs, pidgin plugins, Asterix plugins. Apache plugins, etc.

This way Skype still gets to control their protocol and their network, but at the same time reap most of the advantages of having lots of other people develop on them, and build Skype into things.

What are the odds they would do something that makes so much sense?

Idea: Design for a GFS on top of AWS S3

I know that someone has already written a distributed multimountable filesystem for S3. But it's commercial and closed source.

I've not looked at how it works. But I've been thinking...

There exist already filesystems that are based on preallocated extents, and filesystems that are based on immutable extents. One can combine the two, and build a filesystem that builds on S3, like so...

Each inode structure is an S3 item. Also, each extent is likewise an S3 item. Actually, they are a sequence of S3 items, because they will be versioned. Every time an inode is changed, or an extent is modified, what actually happens is a new one gets written to S3, and the item names for them have a delimited suffix with the version number.

This allows multiple hosts to mount the filesystem readwrite, without being incoherent, and without needing a "live" distributed lock manager. If a host has it mounted, and is reading from some extent, and some other host writes to that extent, the first host will keep reading from the old one.

On a regular basis, such as on sync, a host will issue a list request against all the extents and inodes it is using. It will then thus discover any updated ones, and act accordingly.

Also, each host will write a "ping" item, probably at every such sync. Something can monitor the bucket, and delete all extents and inodes that are older than newest ping of the farthest behind mounting host.

If instead old extents are not deleted after they are obsoleted, it would in fact be possible to mount the filesystem readonly as it appeared at time X, for any arbitrary time between "now" and "just ahead of the reaper process".