andymatuschak.org: archive

My summer vacation is basically over. Uh-oh. I’d better write something on here before I get sucked back into nothingness.

I’ve returned to Caltech and moved into my new apartment (which is huge and fantastic). Since my arrival, though, I’ve been very busy practicing with my a cappella group, Fluid Dynamics.

Yesterday, we went to the freshmen orientation camp and performed for the entire incoming class. You might say we were under just a bit of pressure to impress. Fortunately, the show went fantastically well—I think we made a lot of new fans.

I’m still hoping to get a substantial part of Sparkle 2 done before classes start on Monday, but with all the people arriving, I’m finding increasingly difficult to concentrate. Software update is not exactly exciting.

Prefrosh have arrived. They are tasty.

Do not fear—I’ve not forgotten Sparkle. The progress simply hasn’t been showing up on Trac because David Symonds, who’s been giving me a hand, convinced me to give Git a try.

To be frank, I’m finding it terribly obtuse and much more difficult than Darcs, which seems to have an equivalent feature-set (except for the whole being-really-slow part). Or maybe I’m just not power-user enough to see the difference.

In any case, to follow along while I experiment with this new RCS, you can check out the graphiclog (okay, that’s a cool feature) or the project summary.

Highlights of the last couple days: posets are implemented, and the Atom parser is pretty much done, though it needs to be cleaned up a bit. I’ve also refined the format since I last wrote on it; you can read a new sample here.

This will be cool, I think. I’m not getting distracted from Sparkle 2, I swear.

It also happens to be written in RubyCocoa, which I am enjoying immensely. Also check out RubyObjC, which is superior technically but seems less polished. Maybe I’m wrong—feel free to weigh in.

More on why it’s a lot more fun to code in Ruby than in Obj-C later.

I spent much of the day defining the update feed format for Sparkle 2. I posted a proposal for it on the Conspiratory. Just reading it actually covers a lot of the new features I’m planning.

Some highlights:

• We’re using Atom now.
• Everything is much, much cleaner.
• We’re using posets for versioning now. No more guessing on version number comparison
• Sparkle supports branching, so you can have a beta branch that only users who ask for beta kind of updates will get moved to. Or you can have a 2.x branch and keep updating 1.x.
• Sparkle will support paid upgrades gracefully.
• There’s support for binary diffs through mojopatch. This will be awesome; most updates will change very little compared the whole app’s size, and resources generally won’t need updating.
• DSA signatures are required for everything now.

Please join the discussion on the Wiki. I’m sure parts could be better. Now back to coding.

I’m making good progress with Sparkle 2, but it occurs to me that since DSA signatures are going to be required, and branching is much more complicated, it’d be great to have an appcast making app that would create and update developers’ appcasts.

Here’s what I envision:

Storyboard

• User drops their .app onto SparkleCaster for the first time.
• SparkleCaster reads all the relevant info from the bundle and creates a profile for the app, asking the user for S/FTP access and so on.
• SparkleCaster generates DSA keys for the app (or takes the user’s if they want) and keeps track of them.
• SparkleCaster generates a differential binary patch.
• SparkleCaster collects any additional information it requires for the version like branch and release notes (the rest it scraped from the info.plist), makes the appcast, and uploads it.
• In the future, when new version of the .app are dropped onto SparkleCaster, it uses the old app profile and just collects the small amount of information about that version.

There would probably have to be some actual managing kind of interface, too, in addition to that simple process—especially if I allow developers to recall bad updates, which is really appealing.

The only problem with all this is that I’m not even a little bit going to have time to write it. School will be starting, and I’m also continuing my summer research, so even getting Sparkle 2 done will be tense.

So! Would anyone like to write this thing, working alongside me as I write Sparkle 2? It’s a big chance to get your name out there and to make a lot of developers happy.