[Sparkle] Thinking about unifying Sparkle...

[Martin Redington]

While I can see the value in where you're going with this, I think
there are quite a lot of potential downsides to this approach.

Please keep the current mode of functioning viable as well - if the
user gets a message saying "do you want to use sparkeplus to update
this app", and otherwise they fall back to the "old" (current)
behaviour, that would be fine.

Re John Gruber's original comment. I put a "check for updates" menu
item in my apps - is it really so hard to hit skip, and then come back
and hit the menu item at a more convenient time (not that there aren't
other valid reasons for the kind of system you're proposing).


On 8/5/07, Andy Matuschak <andy at andymatuschak.org> wrote:
> > 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
> _______________________________________________
> Sparkle mailing list
> Sparkle at lists.andymatuschak.org
> http://lists.andymatuschak.org/listinfo.cgi/sparkle-andymatuschak.org
>