[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