[Sparkle] Proposed solution

[Andy Matuschak]

On Aug 6, 2007, at 12:20 AM, David Symonds wrote:
> I've thrown a quick sample RSS <item> [with posets] in at the bottom  
> of that page,
> though it is very rough.

Excellent work, David. I like this. It's not too complicated at all  
unless you want it to be. I'm thinking if there's no  
<sparkle:supersedes> tags, I'll just do old-style version comparison  
and assume they want linearity. Though that's not necessary if I make  
an appcast-maker-dealy.

And I can do the awesome encrypted branches under this model if I feel  
like it. Those would be really cool.

On Aug 6, 2007, at 12:49 AM, Florian Albrecht wrote:
> Put yourself in the position of the user: You downloaded an app from  
> a website, not exactly knowing what it is, but it looks interesting.  
> You just want to have a look at it. Depending the app you probably  
> need to run an installer or do any other setup voodoo. Now, as  you  
> finally think you are ready to give it a try it bothers you by  
> having to make a decision whether you want that app to automatically  
> do the update thing.

You're absolutely right. It's not quite so bad, since it'd only be one  
time instead of once for every app, but it's disruptive, and it sucks.  
How about asking the user on the second launch? I don't think that'd  
be quite so bad. They like the app; they've come back to it. The first  
impression has already been made. This is what Panic does.

> Have you thought about different Sparkle versions having to be  
> compatible at all times? Or how would we handle different Sparkle  
> versions?

Sorry, do you mean Sparkle 1.x incompatible with Sparkle 2.x? That's a  
little tricky: I'll either have to not change the appcast format  
drastically, or developers will have to keep around their Sparkle 1.x  
appcast and have the most recent update in that appcast use a Sparkle  
2.x appcast instead. This rather sucks.

If you mean between different Sparkle 2.x framework versions in  
the .apps, that's not an issue: the code in the .app doesn't do  
anything (in this model) besides install the prefpane and daemon. The  
daemon then takes care of checking all the apps. The appcast format  
would have to be defined well-enough that checking an older app  
couldn't cause issues.

The other advantage of this that I've only now realized is that this  
means Sparkle can update itself.

> For me it is still very alienating that some unknown icon appears in  
> my Dock each time I start Photoshop CS3. As it turns out, it's there  
> (rather ugly) software updater trying to catch my attention while  
> checking all sorts of things.

Another excellent point. I'm thinking that the dialog requesting the  
installation will have the Sparkle icon in it, so it won't be  
completely foreign, and after they look at it once, it'll be  
memorable. I hope. Best I can do, I think.

> If you make it *identical*, people will not see that it's not  
> Apple's Software Update. This might be good or bad. In our  
> experience I'd rather have something specific to refer to in case of  
> a support incident.

It'll have the Sparkle icon in the upper-left instead of Apple's  
Software Update icon. Hopefully that'll be enough.

Thanks for all your (very salient) feedback, Florian!

- Andy Matuschak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andymatuschak.org/private.cgi/sparkle-andymatuschak.org/attachments/20070806/6dde7292/attachment-0001.htm