[vlc-devel] Future of the update mechanism

Dominique Leuenberger dominique at leuenberger.net
Thu Jul 30 18:11:27 CEST 2009


Quoting Francois Cartegnie <fcvlcdev at free.fr>:

> Le jeudi 30 juillet 2009, Jean-Baptiste Kempf a écrit :
>> On Thu, Jul 30, 2009 at 05:26:32PM +0200, Rafaël Carré wrote :
>> > For my own curiosity, does someone know how much users did use the
>> > update mechanism? (download stats of update.videolan.org/status*)
>>
>> Around 1.5M requests per day.
>
> Why not trying to lower the servers load with next releases ?
> I suggest using name resolution for checking updates instead of hitting http
> servers:
> - My version is 0.9.0 and update sequence is 101.
> - If there's a new version 102 will exist.
> - DNS query for update102.updates.videolan.org
> - if reply is (example) 110.110.110.110 then no update is available
> - if reply is (example) 111.111.111.111 then query by http for filename (1)

The DNS way sounds very interesting, BUT this imposes the problem that  
you'd need to carry on the 'old' update list forever. A relatively  
ugly setup.

But on top of that suggestion, using a DNS TXT record could more or  
less serve what we look for:

update TXT "<update><item os=windows version=1.0.1  
filename=vlc-1.0.1.exe link=http://www.videolan.org/mirroredlinkto.exe  
action=suggestDownload /><item os=openSUSE version=1.0.1  
link=http://www.videolan.org/suse/readme.html action=ShowReadme  
/></update>"

I'm sure you get the idea.
Instead of putting all the OS infos into one big TXT record, those  
could be split in smaller records, update.opensuse, update.win,  
update.mac or whatever.

The nice thing is the size of DNS queries, their nature of being  
cached (with proper TTLs being set). And with the content itself we  
can basically do whatever we want.

Dominique



More information about the vlc-devel mailing list