Farhad Manjoo writing in Slate about Google Wave:

The trouble is, everything you type into Wave is transmitted live, in real time—every keystroke was getting sent to Zach just as I hit it. This made me too self-conscious to get my thoughts across.

… Maybe I should just delete what I’d written and say, “Twitter works because it’s simple.” But I couldn’t do that, because Zach was watching me. He could see me struggling right now—he could see that I’d gotten myself stuck in a textual cul-de-sac and that I was desperately searching for a way out without looking foolish. Now I saw Zach beginning to type: “Don’t let the live-typing get you down!” The game was up; what was the point of making a point now? I ended my thought clumsily and then resolved never to attempt to say anything very deep on Wave.

The same thing happened seven years ago with the live-typing feature that I implemented in iChat 1.0 (which was only supported for Bonjour chats.) I thought it was an awesome idea, and I’d wanted to have it in a chat program since about 1997. But it turned out that, in actual use, people hated it, for exactly the reasons Manjoo describes: it makes you self-conscious. We took it out in the next release.

(Interestingly, I hate video chat for a very similar reason. Somehow, the fact that my picture is being shown in real time to the remote person makes me horrifically self-conscious, even though it wouldn’t bother me at all to talk face-to-face with that person. I don’t know whether it’s the little preview on my screen, or the fact that the person is spookily both present and not-present, but the few times I’ve tried video-chat have been really unpleasant.)

I’m usually on the side of more technology. I believe that our online communications tools are still horribly primitive and have only scratched the surface of what’s possible. But this was a case where more technology was bad.

The low-tech alternative that lots of people use in IM,
is to write in short fragments,
each a separate message,
so the other person can see them one by one
without waiting for you to finish the whole sentence.

The difference is that you’re in control over when to send a partial message, and the other person knows you’re in control, and so on. I still think it might be possible to do this in a higher-tech way, like using a hot-key to send a partial message on demand without having the funky line-breaks, but the current approach isn’t so bad as long as you’re not embarrassed about unintentional free verse.

I could have told the Wave people about what I’d learned, except I didn’t know Wave existed until April (shortly before the public announcement), and even then I was just some guy lost in the crowd at the demos….

Part of the problem, in both cases, is that live typing is one of those Cool Demo Features that looks really awesome when showing off the app. Features like that can be dangerous because they are legitimately very useful during the app’s gestation, when exciting demos are a key survival trait; but then they can’t be removed later on because they’re so well-known, even if they turn out to be useless. Sometimes these features aren’t actually harmful to the user experience, they just make the code more complex and harder to maintain. Instant typing is both, unfortunately. (The clever sync algorithms and rapid-fire network messages Wave uses would be needed even without live typing, but the fact that they have to run on every few keystrokes, not just every minute or so, pushes those things so much harder.)

I’ve pushed out a few updates to the Ottoman library today. These fix a couple of embarrassing bugs, and also add an API in regular ol’ Objective-C for those of you who aren’t into that funky “C++” stuff.

(The Cocoa stuff uses MYUtilities, so if you’re not already using that, please read the setup instructions.)

It’s got a moose! But then I found the ottoman with hanging files inside and it was even more perfect…

I thought this one was pretty damn stylish too:

As promised …

Ottoman is a lightweight, reliable key-value store with multi-version concurrency control.

A key-value store is a persistent on-disk dictionary that maps arbitrary keys (usually short text strings) to arbitrary values (binary data of any length). There’s already a large and venerable family of libraries that do this, often referred to by the name “db”. Notable members include dbm, Berkeley DB, cdb and Tokyo Cabinet. What makes Ottoman different?

1. It tries to provide extremely reliable storage, immune to file corruption caused by operating system crashes or power failure while writing.
2. It stores past versions of the database, as a useful side-effect of the way it works. Applications can use this to provide features like snapshots, timelines or persistent undo. (You can prune old versions, for space or privacy reasons, by writing a fresh copy of the file.)
3. It has very low memory overhead. The file and its contents are memory-mapped, so even large values can be accessed without having to copy them into the heap. (Opening a database only mallocs a few hundred bytes!)
4. It allows concurrent read/write access by multiple processes. Optimistic concurrency — as used by version-control systems like Subversion — keeps file locking to a minimum: readers are //never// blocked at all, and writers are only blocked briefly (clients can’t lock the database for arbitrary periods, only for as long as it takes the accumulated changes to be written to disk.)

Why is it named after a footstool? First, as an homage to CouchDB. Secondly, it turns out ottomans can be used for storage. Third, because I have a mild fascination with Asian and Islamic history.

_…Read more at the project home page!_

So far, this blog’s main claim to fame has been as the #2-ranked Google hit for [apricot jam recipe]. But that’s no longer enough to sustain my extravagant lifestyle, so I’m following the next most obvious business opportunity: Elephant jokes! These were huge (the jokes) when I was a kid, but they seem to have been largely forgotten, which is a shame. I tested them out on my kids today, and they still work fine.

These jokes are, admittedly, about as unoriginal as my jam recipe. And the list was generated roughly the same way as the jam, by picking pre-existing collections, cleaning off the typos, and boiling them down a lot. In fact, I’ll lead off with an apricot joke:

Q: How is an elephant like an apricot?
A: They are both gray. Well, except the apricot.

Q: How can you tell if an elephant is in the refrigerator?
A: The door won’t shut.

Q: How can you tell if an elephant has been in the refrigerator earlier?
A: Footprints in the butter.

Q: How do you get an elephant into the fridge in the first place?
A: Open door; Insert elephant; Close door.

Q: How do you get a giraffe into the fridge?
A: Open door; Remove elephant; Insert giraffe; Close door.

Q: What’s the difference between a dozen eggs and an elephant?
A: If you don’t know, I’m sure not going to send you to the store for a dozen eggs!

Q: What the difference between a herd of elephants and a bunch of grapes?
A: Grapes are purple, elephants are gray.

Q: How do you stop a charging elephant?
A: Take away his credit card.

Q: What did Tarzan say when the elephants charged?
A: “Look out, here come the elephants!”

Q: What did Tarzan say when he saw a herd of elephants in the distance?
A: “Look, a herd of elephants in the distance!”

Q: What did Tarzan say when he saw a herd of elephants with sunglasses?
A: Nothing. He didn’t recognize them.

Q: What did Tarzan say when he saw a herd of giraffes in the distance?
A: “Haha! You fooled me once with those disguises, but not this time!”

Q: What did Jane say when she saw a herd of elephants in the distance?
A: “Look! A herd of grapes in the distance!” [Jane is color blind.]

Q: Why are pygmies so short?
A: They listened to Jane, and looked at the plums.

Q: How do you get down from an elephant?
A: You don’t! You get down from a goose.

Q: How does an elephant get down from a tree?
A: He doesn’t! Even elephants know you get down from a goose!

Q: Oh, all right. How do elephants get out of trees?
A: They float down on the leaves between 4pm and 6pm.

Q: What do you call an elephant that rides a bus?
A: A passenger.

Q: Why don’t African elephants like to play cards?
A: Because of all the cheetahs.

Q: What’s the difference between an African elephant and an Indian elephant?
A: About 3,000 miles.

Q: Why do elephants wear sandals?
A: So that they don’t sink in the sand.

Q: Why do ostriches stick their head in the ground?
A: They’re looking for the elephants that forgot to wear their sandals.

Q: What did the peanut say to the elephant?
A: Nothing: peanuts can’t talk.

Q: What did the grape say when the elephant stepped on it?
A: Nothing: it just let out a little whine.

Q: Why did the elephant fall out of the tree?
A₁: She slipped.
A₂: She was dead.

Q: Why did the second elephant fall out of the tree?
A: He was glued to the first one.

Q: Why did the third elephant fall out of the tree?
A: He thought it was a game.

Q: Why did the fourth elephant fall out of the tree?
A: Because when his mother asked “If all your friends jumped out of a tree, would you?”, he said “Yes!”

Q: Why did the tree fall down?
A: It thought it was an elephant.

Q: What’s gray on the inside and red and white on the outside?
A: Campbell’s Cream Of Elephant Soup.

Q: Why did the elephant stand on the marshmallow?
A: So he wouldn’t fall into the hot chocolate.

Q: What do you know when you see three elephants walking down the street wearing pink sweatshirts?
A: They’re all on the same team.

Q: What’s gray and has four legs and a trunk?
A: A mouse going on vacation.

Q: What do you call an elephant with a machine gun?
A: “Sir”.

Q: What do you call an elephant wearing pink earmuffs and a dress?
A: Anything you want: it can’t hear you.

Q: Why do elephants drink so much?
A: To try to forget.

Q: What’s gray, yellow, gray, yellow, gray, yellow, gray, yellow … ?
A: An elephant rolling down a hill with a daisy in its mouth.

Q: What’s gray, yellow, gray, yellow, THUMP, gray, black, blue, gray, black, blue … ?
A: An elephant rolling down a hill with a daisy in its mouth, that hit a rock.

Q: Why do ducks have flat feet?
A: So they can stamp out forest fires.

Q: Why do elephants have such large, tough feet?
A: So they can stamp out flaming ducks.

Q: What’s gray and puts out forest fires?
A: Smokey The Elephant.

Q: What do you get when you cross elephants with peanut butter?
A₁: Elephants that stick to the roof of your mouth.
A₂: Elephants that spread easily.

Q: Why did the elephant wear red sneakers?
A: So he could hide in the apple tree.

Q: Why do elephants paint their toenails red?
A: To hide in cherry trees.

Q: Why do elephants hide in cherry trees?
A: So they can jump out and stomp on people.

Q: How did Tarzan die?
A: Picking cherries.

Q: What do you get if you cross an elephant with a kangaroo?
A: Big holes all over Australia.

Q: What kind of elephants live at the North Pole?
A: Cold ones.

Q: What’s convenient and weighs 20,000 pounds?
A: An elephant six-pack.

Q: How do elephants talk to each other?
A: By ‘elephone.

Q: Why do elephants have cracks between their toes?
A: For carrying their library cards.

Q: What’s gray, has large wings, a long nose, and gives money to elephants?
A: The Tusk Fairy.

Q: Where do elephants with skin problems go?
A: Pachydermatologists.

Q: What do you get when you cross an elephant with a rhinoceros?
A: Eliphino _(Hell-if-I-Know)_

Q: What’s the difference between an elephant and a piece of paper?
A: You can’t make a paper airplane out of an elephant.

Q: How do you make an elephant float?
A: Take two scoops of ice cream, some soda, and one elephant.

Q: How can you tell if there’s an elephant in the ice cream shop?
A: His bike is outside.

Q: How can you tell if there are two elephants in the ice cream shop?
A: There’s a dent in the cross-bar.

Q: How can you tell if there are three elephants in the ice cream shop?
A: Stand on the bike and have a look in the window.

Q: Why do elephants have gray skin?
A: To hold their insides together.

Q: Why are elephants so wrinkled?
A: Have you ever tried to iron one?

Q: Why do elephants have trunks?
A₁: Because they’d look silly with glove compartments.
A₂: Because they don’t have pockets.

Q: Why do elephants have wrinkled knees?
A: From playing marbles.

Q: Why do elephants have crinkly feet?
A: To give the ants a chance.

Q: Why are elephants large, gray and wrinkled?
A: If they were small, round and white, they’d be aspirins.

Q: What time is it when an elephant sits on your fence?
A: Time to get a new fence.

Q: What time is it when an elephant sit on your sofa?
A: Time to get a new sofa.

Q: What time is it when an elephant sits on your toilet?
A: Time to run away.

Q: Where do you find elephants?
A: It depends on where you left them.

Q: What do you say when an elephant sneezes?
A: “Gesundheit”.

Q: How do you fit 5 elephants in a Volkswagen Beetle?
A: Two in the front, two in the back, and one in the glove compartment.

Q: What goes, “Clomp, clomp, clomp, squish, clomp, clomp, clomp, squish?”
A: An elephant with a wet sneaker.

Q: Why did the elephant cross the road?
A: It was the chicken’s day off.

Q: Why did the elephant lie down in the middle of the road?
A: To trip the ants.

Q: What would happen if an elephant sat in front of you at the movies?
A: You would miss most of the show.

Q: What is the biggest type of ant?
A: An eleph-ant.

Q: What’s as big as an elephant, but doesn’t weigh anything?
A: An elephant’s shadow.

Q: Why were the elephants kicked out of the swimming pool?
A: They couldn’t keep their trunks up.

Q: Why wasn’t the elephant allowed on the airplane?
A: Because his trunk wouldn’t fit under the seat.

Q: Why were the elephants the last animals off the ark?
A: Because they had to pack their trunks.

Q: Why did the elephant paint her toenails all different colors?
A: So she could hide in a bag of m&m’s.

Q: What would you get if you crossed two fish with two elephants?
A: A pair of swimming trunks.

Q: What should you do to a blue elephant?
A: Cheer it up.

Q: What should you do to a red elephant?
A: Quit telling it dirty jokes.

Q: What should you do to a yellow elephant?
A: Teach it to be brave.

Q: What should you do to a white elephant?
A: Hold its nose until it turns blue, then follow the directions for a blue elephant.

Q: What should you do to a green elephant?
A₁: Wait until it gets ripe.
A₂: Bury it! You were only supposed to hold its nose until it turned blue.

Q: How did the cheerleader die?
A: She tried to catch an elephant doing a split.

Q: How does an elephant get out of a phone booth?
A: Same way she got in.

Q: Why don’t elephants ride bicycles?
A: They don’t have thumbs to ring the bell.

Q: What weighs 5,000 pounds and wears glass slippers?
A: Cinderelephant!

Q: What has 6 legs, 3 ears, 4 tusks, and 2 trunks?
A: An elephant with spare parts.

Q: What’s large and gray and goes around and around in circles?
A: An elephant stuck in a revolving door.

Q: What do elephants have that no other animals have?
A: Baby elephants.

Q: Why do elephants stomp on people?
A: They like the squishy feeling between their toes.

Q: What game do elephants like to play most?
A: Squash!

Q: What did the cat say to the elephant?
A: “Meow!”

Q: Why do elephants paint the soles of their feet yellow?
A: So they can hide upside-down in the custard.

Q: Did you ever find an elephant in your custard?
A: No? Well, it must work.

Q: How do you catch an elephant?
A: Wait at a street corner, and when you see the elephant raise your hand and yell, “Yo, elephant!”

Q: How does an astronomer catch an elephant?
A: With a telescope, a matchbox, and a pair of tweezers. Go to the jungle, and when you see an elephant, turn the telescope the wrong way around and look through it. The elephant will now be so small that you can pick it up with the tweezers and put it in the matchbox.

Q: How does a programmer catch an elephant?
A: Fly to Cape Town and head east. When you reach the ocean, go slightly north and head west. Keep repeating this until you see an elephant, then grab it.

Q: How does an experienced programmer catch an elephant?
A: The same way; but before you start, you place an elephant at Gibraltar, so you won’t fall into the Mediterranean if there are no elephants.

Q: How do you get an elephant into a matchbox?
A: Take out all the matches first.

Q: How do you get an elephant out of the water?
A: Wet.

Q: How do you get two elephants out of the water?
A: One by one.

Q: How do you smuggle an elephant across the border?
A: Put a slice of bread on each side, and call him “lunch”.

Q: How do you shoot a blue elephant?
A: With a blue elephant gun, of course.

Q: How do you shoot a yellow elephant?
A: Wait for it to run away.

Q: What was the elephant doing on the freeway?
A: About 5 miles per hour.

Q: What do you call two elephants on a bicycle?
A: Optimistic!

Q: What do you get if you take an elephant into the city?
A: Free parking.

Q: What do you get if you take an elephant into work?
A: Sole use of the elevator.

Q: Why do elephants wear tiny green hats?
A: To sneak across a pool table without being seen.

Q: How many elephants does it take to change a light bulb?
A: Don’t be stupid, elephants can’t change light bulbs!

Q: What do you get if you cross an elephant with a whale?
A: A submarine with a built-in snorkel.

Q: How do you know if an elephant’s been sleeping in your bed?
A: Peanut shells under the pillow.

Q: How do you know if there’s an elephant in your bed right now?
A: He has a big ‘E’ on his pajamas’ jacket pocket.

Q: How do you know if there’s an elephant under the bed?
A: Your nose is touching the ceiling.

Q: How do you get an elephant on top of an oak tree?
A: Stand him on an acorn and wait fifty years.

Q: What if you don’t want to wait fifty years?
A: Parachute him from an airplane.

Q: Why isn’t it safe to climb oak trees between 2 and 4 in the afternoon?
A: Because that is when the elephants practice their parachute jumping.

Q: Why are elephants’ feet shaped that way?
A: To fit on lily pads.

Q: Why isn’t it safe to go into the pond between 4 and 6 in the afternoon?
A: That’s when the elephants are walking on the lily pads.

Q: Why are frogs so short?
A: They go onto the lily pads between 4 and 6 in the afternoon.

Q: What do you give a seasick elephant?
A: Lots of room.

Q: What’s more difficult than getting an elephant into the back seat of your car?
A: Getting two elephants into the back seat of your car.

Q: How do you know when an elephant has been in the baby carriage?
A: By the footprints on the baby’s forehead.

Q: Why did the elephant wear sunglasses?
A: With all the silly elephant jokes going around, it didn’t want to be recognized.

Q: What do elephants do for laughs?
A: They tell people jokes.

I finally bit the bullet and upgraded to the latest WordPress from the seriously prehistoric version I used to run (I think it was 2.0.4 or something like that.) With the current attacks against older versions, it finally seemed like a worthwhile thing to waste an afternoon on. :-P

Almost everything should work more or less the same. I’ve taken the opportunity to move to a subdomain—jens.mooseyard.com—but the old URLs redirect. The theme is different, because my hacked-up, customized old theme probably wouldn’t have survived the upgrade intact. I can’t say I like this one better, but it’ll do.
Read the rest of this entry »

I know, three weeks ago I said I was building me a B-Tree. I did build it, even the parts I listed under “What’s next?” in that post, and it works. But it became apparent there was a more urgent need for a hash table, for work-related reasons, so I switched gears to build one of those on the same principles.

The biggest principle is Append-Only Storage, as described in the prior post. So I thought back to the simplest on-disk hash table I know of—Dan Bernstein’s CDB—which is very clever, but read-only. I implemented something similar, and then mashed in the CouchDB-like approach of incrementally appending only the modified sub-components.

Initially I made the file a series of key-value pairs, followed by the hash-table index as an array of {hash code, position} structures, each of which pointed to the position of the corresponding key and value. Very simple. To save changes, I’d write out the changed pairs, followed by a new copy of the index. The problem with that was that the index gets large as the number of records increases, so with a 100,000-record file, changing even one record would append almost a megabyte.

I had a brainstorm about how to fix that—add a bit of tree structure. So now there’s a root index of 256 pointers to sub-indexes. The 8 most significant bits of the key’s hash code are looked up in the root index to find the sub-index (hash table) in which to look up the value. The advantage is that every value change only alters one sub-index; when saving, only sub-indexes that were modified, plus the root, have to be written out. So if only one key changes, that’s just one sub-index, meaning only 1/256 as much data to append as before.

[I thought I was really clever for coming up with this, but then when I went back and looked at the original CDB, which I hadn’t seen in a year and a half, it turns out it does it too! I guess I’d just forgotten about that…]

What I have now

What I have now is a persistent dictionary whose keys and values can be arbitrary data blobs. You can make changes in memory, and then save them back to disk, where they’re appended to the file. (Or you can rewrite the file from scratch, which takes a bit longer but reclaims wasted space.) The file format should be virtually un-corruptible by crashes, unlike a traditional database such as sqlite. An interesting extra benefit is better concurrency—the file doesn’t require any form of read-locking, because it’s perfectly safe for one client to write to the file while another is reading from it.

(The grand total’s about 3400 lines of C++, for both the tree and hash table.)

I plan to upload this to Bitbucket soon, but I keep brutally refactoring the classes, or maliciously changing the file format, neither of which would endear me to other people trying to use the code. Hopefully things will settle down soon, now that I’ve got nearly all the functionality I want. I’ll let you know.

[Update: Struck out a comparison that’s probably unfair to current versions of sqlite, judging by descriptions of how it saves transactions.]

Last year I wrote a series of blog posts about a peer-to-peer system called Cloudy that I was developing. I was going up the stack, from messaging to identity, but didn’t finish documenting all the layers I’d built. I mostly stopped working on Cloudy after I went back to gainful employment, but I keep thinking about this stuff.

“Lakitu”?

I’ve since heard about another unrelated project nicknamed Cloudy; and the whole term “cloud” has gotten so debased in the past year that it now stands for outsourcing to giant hidden server farms, which is the antithesis of what I stand for. So I’ve decided to use the name Lakitu instead. Nintendo fans will recognize Lakitu as a bit character in the Mario games—he’s a goggled turtle who rides a little one-seater cloud. This makes him an appropriate mascot for P2P technologies, I think.

[I’m sure Nintendo has a trademark on the character, but they don’t appear to have copyrighted the word “Lakitu”. He’s not even known by that name in Japan, where he’s called “ジュゲム” or “Jugem”. I have been unable to find out what “Lakitu” means or why they decided to use it in the English translation. I could also note threateningly that I have some intellectual-property issues of my own with Nintendo’s depiction of Lakitu’s smiling cloud, which is clearly infringing on my son’s comic-strip character Cloudy. So let’s call it a draw, Iwata-san?]

My last Cloudy post was about verifying people’s identities, and the next one was going to be about gossip. I’ve become unhappy about the rather kludgy way I designed gossip in Cloudy, so yesterday I started designing a new protocol for it, which I’m going to write about.

“Gossip”?

A gossip protocol is a means of broadcasting information in a distributed system. Pairs of computers periodically connect and swap new bits of information with each other; the result is that the information gets dispersed through the whole network (provided it’s a connected graph.) The tricky part is avoiding infinite loops and combinatorial explosions, and optimizing the way pairs of computers swap messages so it scales well.

I started defining a protocol, based on stuff I’ve been thinking about for a while. I don’t think it’s as advanced as what’s reported in research papers, but I’m hoping it will work well enough when used in a socially-driven network—one where the connections between machines are driven by the social connections between their users. Social networks have short horizons, so any particular participant only “sees” a constrained number of near-neighbors even though the entire network may be huge.

I’m making this protocol agnostic as to the type of messaging being used. BLIP will work well, but it ought to be possible to use Jabber or even email; anything that can send messages between two participants. It’s also agnostic as to message content, beyond a few simple assumptions that a message has an author, a timestamp, and some arbitrary “topic” tags.

For example, it ought to work fine at distributing tweet-like micro-blog posts.

Right now I have the protocol written down as an outline in Notebook. I’ll flatten it out, expand it and post it here in a day or two.

The other day I took it into my head to implement a B+tree. Why? Because they sound neat, and I’ve done hardly any serious programming with trees in my career. (Someone, I think Buzz Andersen, once noted that there are two kinds of programmers: those who do think in terms of trees, and those who do everything with hash tables. I’m in the latter camp.)

And also because I’m a big fan of CouchDB, and really admire its elegant storage model. It’s an on-disk B-tree—no surprises there—but the file is append-only, which both makes it impervious to crash-related corruption, provides nearly lockless concurrency, and makes it easy to access earlier revisions.

[In a nutshell: Updated data values or tree nodes are appended to the file instead of overwriting the earlier versions. Since updating a node changes its location, its parent node needs to be updated too to point to the new location. This recurses up the tree, meaning any change ends up with a new root node written at the very end of the file. In fact, when you open the file you find the root by looking at the very end. Since no data is ever changed, once you open the file you’re impervious to changes made by other writers since they don’t affect anything you’re looking at.]

I’d love to use something like that for various projects, but as CouchDB is implemented in the exotic functional language Erlang, I can’t really use its storage layer as-is. So: could I implement something like it in C++?

Thus far I have a working in-memory B+tree implementation. Inserts and deletes work, and I’m working on the iterator. Even this much was harder to get working than it should have been, or so it feels. But that always seems to be true—algorithms sound straightforward when you read about them, but putting them into practice exposes you to all the details and subtleties inherent in hand-waving like “now merge the node with a neighbor”.

Actually I haven’t implemented a straight B+tree, rather a ‘top-down’ variant described by Ohad Rodeh that’s better suited to this type of application because it changes fewer numbers of interior nodes during an update.

What’s next?

• Support for string keys (so far it just handles ints)
• Serializing nodes to/from disk
• Keeping track of which nodes are touched during an operation, and appending those to the file
• Writing a trailer to the file to mark a successful update (and to link back to the previous trailer, for historical purposes.)

Sounds straightforward, but of course the devil’s in the details.

AppleInsider reports on the iTunes 9 rumors:

“The social networking integration that we reported iTunes 9 would have seems to be part of a bigger social networking push by Apple,” the report states. “We’ve been informed that Apple has plans to tie iTunes 9 into a “Social” application that they plan to release in the future.”

This sounds like the kind of app (though separate from iTunes) that Jessica Kahn and I kept trying in vain to get Apple to build, circa 2003-2005. Maybe they’ll get some use out of our abandoned prototypes.

The report goes on to say that the new application would allow users to share their listening habits with friends [and] send music to friends”

Mike Estee and I had actually prototyped this in iChat in 2003, but the feature never got approved since there were so many more important things to add, like 3-way video conferencing. (Plus the fact that Apple execs turned white as a sheet if you said the words “send music” near them.)

Anyway, personal bitterness aside, I think it’s really amusing that Apple keeps shoving the kitchen sink into iTunes, since that has to be the single nastiest, hardest-to-extend codebase they have — it’s their last remaining Carbon app, with a foundation that dates back to Casady & Greene’s SoundJam, circa 1998.