[Sparkle] Thinking about unifying Sparkle...

[Andy Matuschak]

> The first gotcha I see with this is that program configuration and
> environments are often not backward compatible. Newer versions update
> various things so that installing an older version would not work.
> You'd need some way to indicate that.

Very true. I'd say we could have some special tag to indicate that,  
but you know what? I bet 90% of the time the developer has no idea  
they've made some non-backwards-compatible change. That's fine; screw  
it. Maybe still have the rollback feature with a warning to users? Eh.  
It's probably not necessary at all.

> I'd suggest using posets to represent version changes, which could be
> encoded fairly compactly in an appcast, so the whole clunky
> version-guessing-game can be almost completely removed.

Can you give me an example of how you see this working? Another issue  
is the UI for selecting which branch to be on. If there's a simple  
list of branches, we could just have a default branch and then options  
in the prefpane. But posets aren't that simple. Also, it'd be nice to  
be able to give the developer some control somehow over access to  
difference branches.

We could do something crazy like doing public-private encryption of  
branches of the appcast, then the developer could send .sparklekey  
files to his closed beta testers; when double-clicked, Sparkle would  
be able to decrypt that branch. And it would pass along some unique  
identifier with every request, too, so it'd be obvious if it leaked.  
This also sort of assumes a simple list of branches, though. Feh.

- Andy Matuschak