Herewith, a rant: multiple transport bindings considered harmful.

I still hear this and it's getting increasingly annoying. People consider it a good thing for a standard to be able to run over HTTP, BEEP and something else. Has this ever proven to be a good idea? Layering is good for other reasons, but not because it gives implementors a choice that leads to interoperability failure in many cases.

Is it a failure on the part of the designer to understand the usage characteristics of their protocol, and successfully map that onto TCP (connection-oriented), HTTP (stateless respond-and-forget) or something else?

SOAP is supposed to be transport-independent and offer choice, but as I overheard last week, there's a reason they call it web services. And the ultimate in multiple-transport wankery: I once heard somebody propose a schema which they said would run over SOAP or HTTP.

Are there use cases I'm unaware of, where this has been a really good thing for some standard?

I'd like to be able to explain the important confluence of several ad-hoc Web standards to various people, so I paid attention Monday at IIW. This is the diagram I saw:



I can't call this a stack. I just can't. It's not a protocol stack or an API stack or a library stack. The best I can say is that "Some people call it a stack". There's no layering relationship between these things; there's not even a sequence or an order.

PortableContacts extends Open Social and the rest are independent proposals that work well together. It's a suite, a cluster or a collection of protocols/APIs. Here's a first stab at a moderately simple diagram that does not mislead:

Comments?

The idea of using native HTTP resources to RESTfully access an email store is not only an old idea, it's been implemented many times. Some Web mail architectures are even somewhat RESTful although the purest implementations are not themselves Web UIs -- these RESTful email interfaces have typically been built to support Web UI frontends in a classic tiered architecture.

I have been talking about this for so long that it seems self-explanatory. Emails can be HTTP resources with persistent URLs and machine-readable representations. Mailboxes can also be HTTP resources with persistent URLs and machine-readable listings of contents, we just have to agree how to represent those listings. Here's my proposal.

Atom feeds is my choice for organizing those listings. I think it's worth explaining the two overriding reasons why.

1. Atom allows clients to just GET a representation of a feed, and the feed can contain an arbitrarily long list of items, but paged according to the server's needs. This is a great allocation of responsibility, making client logic simple and putting server performance in the server's hands.
2. The default model for feeds is that the same object can be in more than one feed. This is very important for the usability of email going forward. I know a few people who organize their mail into strict hierarchical collections, typically using IMAP, and find old email by jumping to the right place in the hierarchy -- but I know far more who rely on giant inboxes, saved searches, flagged email or tagging. The default model for feeds directly accomodates all those usage models.
   

I was very happy to find once I used these principles and applied the feed model, that it fits very well so far. It's possible to implement the spec as a proxy between an IMAP server and a client. It's possible to access a mail feed with an unmodified Atom-capable newsbrowser. This bodes well for implementing and deploying.

There's lots of ways to amuse even a toddler under 2 with a computer. Browse through cuteoverload or icanhascheezburger. My favourite is to find a Flickr group like Animal Parent and Offspring and browse through saying what kind of animal and baby we're looking at.

On Youtube, one of the earliest interesting things, to a baby, is videos of other babies laughing or babbling, and other parents have uploaded a bunch of those. Of course there's more cute animal videos. Elsewhere, there's kids music videos by TMBG and others.

I'm sure there's lots more but I'm not usually so strapped for ideas that I turn to a computer. I have a sore throat and don't want to get up from the couch!

Two IETF tidbits to pass on.

1. An OAuth BOF was approved, and OAuth was submitted as an IETF I-D as fodder for that BOF. I'm excited about this; we at the IETF have been rather floundering around, without much consensus or sustained progress. Two years ago (already!) at the WAE BoF we identified some possible steps forward but there was still much disagreement over basic approaches, both technical and architectural (integrate SASL into HTTP, make requirements for TLS Client auth in HTTP, invent something new for HTTP). Since OAuth is already implemented in several places, perhaps this will leapfrog us past the open-ended "what shall we build" discussions.

2. ALTO is a proposed WG for "Application Layer Traffic Optimization": focusing on P2P file sharing, how can the network provide information to peers to help them pick peers in a way that impacts other users the least? The ALTO charter was sent out for IETF-wide review, and I'm optimistic about its formation as a WG. I've requested a BOF meeting slot, but hoping to turn that into a WG meeting slot.

This was roughly my bike route today to get to a meeting in Redwood City and back. Apparently about 17 miles, on top of my 6 mile bike between home and the office.


View Larger Map

One of the best articles on DRM I've read in a while appears on Penny Arcade, and contains the words "DRM takes a big poo on your best customers". Actually, the full sentence is worth including:

DRM takes a big poo on your best customers -- the ones who've given you money -- whilst doing nothing practical to prevent others from 'stealing' your precious content juices.

Yeah, that's right, punish your friends and give everything away to your enemies. As artists and creators, you do deserve to make money. Perhaps there are other ways than punitive DRM, however.

I'm not into protesting games that use DRM for protest's sake, although I did avoid buying Spore because of its license checking. I just happen to like games that I can play when I like and pay for when I like. I've given money to Puzzle Pirates, which the author of the article is associated with, because the game let me have fun first before paying. Ikariam is similar but taunted me too much with the for-pay goodies so I found that pressure off-putting. Kingdom of Loathing has the best laid-back attitude towards paying and playing. Not only can I take a break without getting punished, they treat my contributions as valued donations, so I feel good when I toss them some meat.

I've been asked a lot about use of SOAP in IETF standards. Most of the time, I think it's overkill and poor for interoperability, because it has a bunch of features that probably aren't needed, and if they are used, will not work unless everybody uses them the same way.

While using HTTP directly suffers from the same problem, at least the problem is not doubled by using SOAP over HTTP. And HTTP benefits from fantastic tool support and connectivity. So without further debate about whether HTTP itself is a bad or a good thing to use, here's how to use it in a standard.

1. Define your objects, these will be HTTP resources. These are the objects people operate on. In Atom, these objects are entries, feeds and service documents. In CalDAV, objects are calendars and events. In a protocol for transferring karma between people, resources might represent individual karma accounts.
   If you can't think of objects but only of services, you may still be able to use HTTP POST to send requests to the service handler and get a response. I guess you're treating your service handler as a kind of object but it's only minimally RESTful to do this.
   
   
2. Don't bother defining the URLs to resources. They'll be HTTP URLs of some kind. Let servers choose and clients discover.
   
   
3. Define operations on your objects/resources. To create a new one, you should be using PUT (if the client can reasonably construct a new URL that the server will find acceptable) or POST if the server will pick a URL. To remove an object, use HTTP DELETE. To update an object by replacing its content, use PUT.
   Some commonoperations are defined in other HTTP extensions already. To update an object by making a change to it, use PATCH. To move or copy an object, use MOVE or COPY.
   
   
4. Define how clients will find resources. E.g. Atom has service documents which locate feeds, and feed documents which locate blog entries. Because of Atom's strongly document-oriented approach, this means Atom uses GET requests for navigation and resource discover. CalDAV, by contrast, uses WebDAV collections for containers, therefore uses PROPFIND for the same purpose.
   You may find in this part of the exercise that you've invented new objects to help navigation and resource discovery work well. Reexamine your object model.
   
   
5. If you need permissions, use the WebDAV ACL model if possible. Hold your nose if you need to. It's better than building one yourself. Leave permissions out entirely if you can wait a revision.
   
   
6. Figure out if you've got any magic or use cases that aren't handled. E.g. CalDAV needed some magic to query calendars to find out "what events occur or reoccur this week". That wasn't solved with a RESTful PROPFIND request, so CalDAV defined some magic and used the REPORT method to carry the request for magic. Define your own new method for this one if you're dying to exert some creativity.
   
   
7. Figure out the details. There are a fair amount. For example, define whether resources have fixed MIME types; whether caching is appropriate, whether ETags are required. It's probably a good exercise to walk through the section headings of the entire HTTP spec and say "Is this required to support, required not to use, or does it interact with our new protocol in some funny way."
   

---

Ok, I wrote this quickly to get it out and I'd love feedback. There are probably other recipes; this is the one I use. Exceptions exist. Void where prohibited.

DjangoCon 1.0 was great, and now I've got the T-shirt, as shown at left (one of 100 printed -- in a real female size, no less, thanks to Leah.) The photo is from my lightning talk wherein I introduced myself and gave 10 reasons why people who use Django might be interested in IETF and how I could help. Also I'm tickled because the photo was taken by Simon Willison, whose blog I've been reading ever since I started using Django.

It's always nice to meet people with common interests, people I've gotten some awareness of online, but it was especially lovely this time. As Cal Henderson (shown left, pic by webmonkey_photos on flickr) pretty much said in the funny roast-style keynote entitled "Why I Hate Django", the core Django people are just too damn nice.

I also had moment after moment of future shock, just thinking about how many more tools we have for self-organizing as groups of people. Blogs, forums, voting widgets, comment fields, shared calendars and shared docs, collaborative bookmarking and tagging. Yes, none of these are new to Django but Django makes sites with these features very easy to create. I got started on dial-in text-only bulletin boards, people -- we're talking 28 kb modem -- consciously moving my reference point further back than it normally is. And on the other side of the coin, Django is such a useful project because of the online collaboration of loosely connected individuals. That's some heavy bootstrapping there.

I am going to attend the first DjangoCon in a couple weeks. Sorry if you have heard about this too late, all the spots are taken. The Django 1.0 release party is still open, however.

Django has been great to use. It's a huge leap from how I used to have to do data-backed Web sites. It does the same things Rails does but for a Python environment, which I prefer.

I look forward to meeting other django-heads for the first time since I started using it. I'm sure I can learn a lot.

Warning: Knitting content has returned, because I need a place to post this picture.



Claudia asked for solutions to keeping sock knitting on the sock needles while carrying it around, and my favorite solution is a little fabric pocket. I measured the fabric an inch wider than the length of the sock needles in question, on the bias so that there would be stretch. Then the pocket is sewn up as shown in the diagram, with extra seams to keep the sock needles from popping out. The knitting hangs out the opening of the pocket, with the flap to fold over (probably optional).

I did my own two pockets in cotton and silk, finishing the raw edgings with a little rolled hem. A super fast hemless solution would be to use a small square of slightly stretchy fleece fabric, which needs no edge finishing.


The reason this works as well as the point protectors is that the hole on the pocket is smaller than the needles are, so it holds the knitting -- remember, the knitting remains mostly outside of the pocket -- narrowly on the center of the needles. It's the same principle as the sock knitting tubes sold here but cheaper.

Google announced support for the CalDAV standard, and explained how to view a Google calendar in Apple's iCal client. There are a few glitches but it's a developer-focused release and they've solicited bug reports.

I would be very interested to know how their WebDAV logic (underlying CalDAV) plays with their Atom logic (underlying the GData API). I'm sure Google Calendar is not the only implementation to support both protocols to view and modify the same data, and there will be more.

Biking around and trailing the toddler is all very well, until you hurt your lower back pushing those pedals, and then have to pick up said toddler. And when I say "you" here, I mean "me" (don't you love the vagueness of the impersonal second person, or "generic you").

The resident expert advised me to pedal faster at lower gears, and to spin the pedals around rather than push them down. Apparently RPMs of more than one per second are common for real cyclists. I started saying "Left, right, left right" to myself to try to get a feel for this rhythm, and it seemed reasonable until I actually got on the bike again and tried to pedal that fast. It feels too fast! Will definitely take some getting used to.

While this may all be very logical and reasonable, it's evidently not what I'm used to. When we were kids we used to have durable, stiff bikes and we'd stand up on the pedals alternately to get moving, putting our full weight on each slow stroke. Besides, the seats were torn up anyway by mistreatment, so why even sit on the seat. I think when I was thirteen, or maybe even twelve, my parents got me a full-size men's mountain bike, figuring it was the last bike they'd buy me before I moved out. It lasted me through university too as I recall. Of course it didn't fit me -- frames for men are too long for most female torsos -- but we didn't know any better about that either.

I recently scanned through Flow, by Mihàly Csíkszentmihályi, a book I first read a decade ago. It didn't improve on rereading -- it's not a bad book, but it has the kind of overblown promises I've come to recognize in a certain category of books by obsessed people. Greater world peace, less illness, better personal finances and fewer unwed teen mothers would result if more people learned to experience more flow. Another book in this category is The Promise of Sleep, by Dr. William C. Dement: if only more people got better sleep we'd see better health, less unemployment and many fewer traffic accidents. Any others?

My husband has been ranting about another category of books: books about a particular invention that "changed the world". The smaller the subject the funnier these are, and these are easy to find with an Amazon search:

• The Machine That Changed the World -- about "lean manufacturing" as introduced by Toyota, basically a PR exercise for Toyota according to reviews.


• Rome 1960: The Olympics that Changed the World


• The Night of the Long Knives: Forty-Eight Hours That Changed the History of the World


• Nixon and Mao: The Week That Changed the World


• The Map That Changed the World: William Smith and the Birth of Modern Geology


• The Gun that Changed the World -- about the Kalashnikov


• Mersey the River That Changed the World


• The Fibre that Changed the World: The Cotton Industry in International Perspective, 1600-1990s


• The Box That Changed the World: Fifty Years of Container Shipping - An Illustrated History


• Tea: The Drink That Changed the World


• Banana: The Fate of the Fruit That Changed the World


• Cod: A Biography of the Fish That Changed the World

I have a yoga rant today. Why are yoga classes so seldom both strong and safe? By "strong" I mean including poses that take strength to hold, and that are held for five or more long breaths, such that the class overall makes one sweat and improves muscle tone. Load-bearing exercise is important for women of all ages for late-life bone strength, and men seem to like these types of classes better because they include some poses that men are good at.

By "safe" I mean that dangerous poses, ones that can harm the wrists or back or knees, are not as frequent and come with careful instruction and warning, and the teacher explains how to do the pose safely and also explains who should not do the pose. Some of the things I hear from yoga teachers I consider "safe":

• Push the base of the fingers down into the mat in poses that put weight on the wrist; this engages the muscles of the hand to protect the wrist.


• Remember to flex the foot in poses that open the hip by using the whole leg as a lever (e.g. the "knee to ankle" pose). Again this activates the muscles that hold the joint solid, rather than stress the ligaments.


• "If this hurts in this way, stop."

Instead, the normal tendency when teachers focus on yoga that doesn't hurt, is to make the whole class easier; while the tendency when building a class for advanced or strong students is to do dangerous poses without teaching how to do them safely.

Anyway, I do know a teacher, currently teaching, who excels at combining strength and safety, although I don't have a schedule that allows me to take her classes right now.

I am not experiencing flow doing Django Web form programming. Don't get me wrong, it's powerful and good, but there is something seriously messing with my ability to keep working. As usual, I need to look up Python and Django and HTML forms details every so often, but this is normal and I've been able to maintain focus doing other kinds of programming.

To build Web forms, I create a new HTML page and see that it loads, add a form element and a form field, see if it shows up, add a submit button, test that it works without being wired up, wire it up to a form submission URL and write a dummy handler, see that the dummy handler is called, replace the dummy handler code with real handler code. Each of these steps takes only a minute or two and after many of them I find I have to stop working rather than go on to the next step. It's worst when I have to figure out "what next" when I'm done with one whole form, at least for the time being. Perhaps it's the constant swapping between deciding "What am I doing" and "How do I do what I decided to do".

This was my route and itinerary by bike last Friday:



I biked three miles to the Palo Alto train station, caught an earlier train than I intended, and arrived 45 minutes early for my 10am meeting at point B. I left there just before 11 am and saw two bridges and much waterfront on my way to point C, where I was 30 minutes early for my noon meeting.

I left C at 1:30 and was 20 minutes early for my 2:30 appointment at point D. Finally I left there at 3:30 and had a last appointment near A before biking back to Caltrain. This SF loop is 12.5 miles according to Google, and I optimized it to have very little hill-climbing but this is SF folks. There were some hills.

The caltrain ride home was very much slowed by a pedestrian accident past Palo Alto, so I got off the train at the unscheduled Menlo Park stop and biked home: 4 miles.

A total of 19.5 miles on bike, all in a skirt with my demo laptop on my back. I loved it!!

Jasmin ordered photos of my red hair and I have complied. It's weird having a conversation via blog posts and comments, you know? I had a little fun with the shooting but was on my own with D. wandering around the patio so I could only do so much.

I visited the Asian Art museum of San Francisco a few years ago with a good friend. We were struck by all the buddhist iconography embodied in the hair of painted gods: peaceful gods had softly flowing blue hair, while wrathful deities had fiercely curling fiery red hair. Like Jasmin:



After seeing all these fierce hairdos, my friend and I immediately went home and dyed our hair bright red. But Jasmin really rocks that look!

UPDATED: I didn't mean to imply this photograph is one I took, but I forgot to give credit for it. 'gretch_dragon' took the photo.

Some news related to my role as an Applications Area Director, for a change. Last week was the P2P Workshop organized by Jon Peterson and Cullen Jennings. I didn't take any notes so I won't have many names to drop, but I learned a lot. In the morning we heard talks from operations guys at Comcast and by Stanislav Shalunov who works on one of the BitTorrent clients. The basic summary of each of the talks was that despite their differences they'd like to work together and with the IETF or for the good of the Internet. Comcast talked about their commitment to net neutrality and the costs/challenges of providing cable service -- neat stuff about how upload bandwidth is completely separate from download bandwidth, and BitTorrent is unusual among applications in using more upload bandwidth than most. Stanislav talked about all the logic they have in the client he works on to be careful about overloading the network despite having very little information available on how to ration network usage.

In the afternoon, I recall a talk on "Localization". I'm used to this meaning to translate software into another language, but in this case the meaning was to find a server that's "local" in network terms before attempting to do something. Leslie Daigle and Henning Shulzrinne also gave talks.

Some of the takeaways for the Applications area could be:
- Documenting the BitTorrent protocol in a stable document
- Standard on how to find an appropriate mirror or location for a resource that's available on multiple servers -- this is re-implemented all the time in the wild, with different confusing HTML interfaces on each implementation
- Standard on how to find a local server -- this could be a subproblem of the basic service discovery problem (given a particular domain), or it could be more sophisticated (not just one domain but based instead on network topology)
- More ways to find out network information -- this could include information on bandwidth available, bandwidth quota, local servers, caches etc.

I don't know exactly how followup from this meeting may turn into Internet-Drafts, WGs or other, so that's all the information I have for now and no predictions of whether people will actually volunteer to do any of the above. But even as is, I thought the workshop was useful for bringing people closer to the same page.