Christopher Atlan has been committing some really useful patches to Sparkle trunk as of late. Among them are support for plugins, support for pkg and mpkg updates, and a couple nice bugfixes. Thanks, Chris!
Sparkle 2 Updates
I haven’t had a chance to actually code on Sparkle 2 (dohgod, Caltech’s killing me so hard), but I thought I’d update blog readers with what I’m thinking, vision-wise, since I haven’t had a chance to update the Conspiratory:
Lots of people in #macsb pointed out that they don’t want their apps asking users if they want to install some third-party crazy preference pane thing that requires authorization. This is understandable. I’m going to make Sparkle 2 a little friendlier than that.
First, there’s the developer side: Sparkle.framework, which contains all the core functionality: code to parse appcasts, to make the version poset, to check authenticity, and so on. Your app can use Sparkle.framework as before to just do updates completely within-app. No creepy install-y prompts.
Then there’s Sparkle, the user-focused thing (should it have some other name? or should Sparkle.framework?). When users install this, they start a localhost-only webserver on some obscure port that acts as the Software Update server for the real, bonafide Software Update.app. This doesn’t require any crazy SIMBL-hackery or anything: a simple preferences .plist setting specifies the host Apple SWU supposed to use to retrieve its update catalog.
So this webserver will serve up .sucatalog files (example) made from the union of the genuine Apple update catalog and a generated catalog of updates available for the apps on your computer. A daemon will update the webserver’s .sucatalog file every so often (daily-ish) by pinging all the appcasts.
A preference pane will switch the webserver on and off; users can switch back to the genuine Apple update server easily, so it shouldn’t be too scary.
And finally, like with Growl, developers can choose to call a quick method in Sparkle.framework that’ll offer to download + install the user-side Sparkle solution. Totally optional, opt-in.
There are some technical details to be worked out behind the software update proxy thing, but I’m pretty confident I can make it happen—this’ll offer the best solution to users, since it’ll be integrated into the interface they already know. There’s only one set of settings for updating, and no duplicated UI.
Not that this’ll actually happen until Caltech stops beating me up and taking my lunch money.
The Conversation {5 comments}
I do not like this idea at all. This is hackery, and will scare people off. If only because their truste apple software update app is suddenly checking an verifying third-party apps.
Naming is ok I think: Many know that Sparkle is used to update their apps, and thus an external updating app/preference pane should be named accordingly. Developer wise it is named Sparkle.framework anyway, I think this gives more then enough distinguishment.
It is a different App and it does deserve a ui of it own, even if it is just a duplicated ui.
Btw. is this what MacOSX Server does? Doesn’t running a web-server all the time, just for whenever “Software Update.app” feels like updating, a bit overkill? Also, if we’re going to modd it to this, maybe make it network-able over bonjour. let one mac look for updates, and serve it up over the LAN.
Again, I’m against (!!!) this kind of integration, but it does offer some advantages, I admit.
One more thing…
As a user, and dev, I wouldn’t mind a dialog à la “This app uses a technology called […] but but updates will also work without installing, only not so smoothly in the background.”
If the dialog is the dialog is understandable, descriptive and also works without installing Sparkle on your system then I wouldn’t mind, at all!
Seriously, you’re only going to see it once.
Yes, this is exactly how the Mac OS X Server does it. And that’s why it’s not hackery: it’s what Apple itself does.
Running a server all the time isn’t unreasonable: you’ve got probably a dozen of them running on your machine right now. If I use a tiny server, it’ll take something like 4mb of RAM and no CPU while Software Update.app isn’t running.
Google Desktop runs a local webserver as well, although perhaps its reputation these days is a little less than savory ;) Regardless, it’s a fairly accepted and non-resource-intensive technique. You just use something nice and lightweight, and it gets paged out when not needed.
I like this idea a lot.
Waldorf: Some (many?) apps already show one or more dialogs on first launch. Adium is my interest, so I’ll use it as the example. There’s a quicksilver-like initial setup wizard, and the growl installer (which I loathe). Adding Sparkle to the list would make three separate things to click through, two of which installed “something”. That’s a lot of trust to ask from a new user, and a lot of hassle for them to actually get to the app.
David: Good point. Though you are going to get this message only once.
Maybe a programatic interface ( [Sparkle install] ?) would be favorable since you (as a dev) could create your own setup wizard, or just incude it in your own installer package as an option.
Leave a Comment
You can follow any responses to this entry via its RSS comments feed. You can also leave a trackback if the inclination is there.