Sparkle 2.0 Conspiratory

Sparkle is scarily widespread already, but I'd really like to take it up a notch. Really make people go "Wow. Look at that software update. That's totally rad." To do that, I want to make Sparkle centralized instead of application-based, and I want to establish a good, solid standard for appcasting that others can use as well.

As we do this, we can dream about crazy, wonderful features we'd like to have in Sparkle, but I'd like you all to keep in mind this core, guiding design principle:

Sparkle must present as little interface to the user as possible. It must appear as infrequently and with as few controls as possible while still remaining useful to the majority of users.

With that brewing in your brilliant brains, I invite you to conspire with me on Sparkle's future.

Topics

Storyboard: How Sparkle 2.0's interface and processes work, step-by-step.
Appcasts: Ironing out a firm appcast format for Sparkle and others concerned.
Updating Non-Apps: How Sparkle 2.0 will deal with bundles, prefpanes, and other non-.apps.

Issues

These are points that aren't quite solidified. Help would be appreciated here.

Branching: We want more awesome branching support.
Licensing: Sparkle should gracefully handle paid N.0 releases.
Automatic Update Installation Notifications: How do we let the user know an update's been installed if he's chosen to have us automatically install updates?
Statistical Information: I've decided to support sending anonymous information in Sparkle2, but where do we ask if it's okay?
Permission Issues: Install for current user? All users? I hate authenticating.
Incremental Updates: Update: Looks like we're using MojoPatch?. Excellent.

Proposals

Package Managers: Sparkle-enabled applications installed by Fink or MacPorts should use those package managers for update information.
Applications with plugins: Sparkle should handle applications with plugins.

Alternative Implementation

Sparkle 2.0 should be an independent application similar to that of Growl. Implement as a user installable preference pane, applications could register with sparkle, such as their name, Appcast location, etc. Plugins would then be able to register independently from the application but establish a connection to the Application so that when the application is launched, along with checking for application specific updates, Sparkle would know to check the plugin's Appcast as well.

The Sparkle.framework installed within the Application could then on the first launch of the Program determine whether the Sparkle system is installed or not and then offer the user the option to install it.

This adds a slight bit of complexity to sparkle, but it should be no harder to add to a program than Growl. It also addresses the issue of plugins and statistical information collection authorizing (Asking the user). By being an independent preference pane application this would allow Sparkle to have one place where a user can set whether or not programs should check for updates on start up (A Global that could be overridden on a per program bases?) . It could also allow a user to set an optional time interval when all registered application are checked for updates. Allow optional fully automatic updates of application. The option are endless, but would be far more easily implemented in this fashion.