[vlc-devel] Future of the update mechanism

[jpd at videolan.org]

On Wed, Jul 29, 2009 at 06:02:12PM +0200, Felix Paul K?hne wrote:
> as most of you known, we are experiencing some problems with the  
> current update mechanism. Some people want to replace it with a simple  
> panel showing the URL of the latest version. This is something I don't  
> really like as it is quite unfriendly for the user. As my roommate put  
> it, the PC is there to do stuff for me and I'm not there to stuff for  
> it => it's obviously a lot easier to let VLC download the binary  
> without web-browser contact.

That kind of thinking is what brought us automatic installing of, say,
activex controls, automated running of foreign code, and so on and so
forth. I'm not saying he's wrong, but he's at best only half right.

Yes, the computer should do stuff for you, but not behind your back: not
without your say-so. That is a hard requirement for not fscking up.

If showing a (clickable) link in a popup hooks into existing
download-and-execute facilities already provided, that saves us a lot of
code and makes the process clear for the operator. All we would need is
a hook in the installer to remove and clean an existing instance first.

If such an approach doesn't work we'll have to re-think our approach.
Personally I am not readily in favour of duplicating another wheel
or even importing someone elses' reinvented wheel. If that means our
updater looks a bit kludgy (but otherwise works reliably and well), then
I'll live with that.


Not to say your description of the framework isn't spiffy, and
securecryptohashcheckverificationing is pretty much required nowadays,
should we want such a thing, but the overriding concern is not how nice
the framework is. What should worry us first is how we present minimum
hassle for /the user/ (including update nagging), combine that with
minimum extra code and complexity for us, and before all else make sure
nothing happens without /the user/'s informed consent.