[vlc-devel] Future of the update mechanism
rafael.carre at gmail.com
Thu Jul 30 17:44:42 CEST 2009
On Thu, 30 Jul 2009 17:22:47 +0200
jpd at videolan.org wrote:
> So, where are the alternatives? How do we know that this particular
> thing is the best currently available, that it meets our needs and
> that we want to solve our problem that way? If so, we can move on to
> deciding whether its drawbacks are worth it. But have we defined our
> problem already? We started with a solution looking for one of those.
> So far, I'm inclined to think not so. Complete failure to discuss even
> the `minimalist' and `none' options are key in that thinking, as is
> lack of other options and this thing's inherent limitations.
> I don't want another salespitch; I want a discussion.
Let me summarize the different solutions:
1/ Let the user check regularly www.videolan.org and install himself
pros: no code, no bugs
cons: more bug reports from people using old versions
2/ Use Sparkle on OSX
pros: bugs in Sparkle are dealt by the Sparkle team
cons: OSX specific, additional server CPU load and $ spending if SSL
is used, but we can use DSA signatures
3/ Use the current code present in src/misc/update.*
pros: already present, could get a bit of love from myself
cons: integration into the GUI(s) is error-prone (a bug in OSX GUI it
prevented updates from 1.0.0 to 1.0.1, and from 1.0.1 to future
releases) and should be reviewed
feel free to correct/enhance this mail
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: not available
More information about the vlc-devel