Get Iplayer for Windows

[dinkypumpkin]

On 08/08/2011 21:47, David Woodhouse wrote:
> On Mon, 2011-08-08 at 19:24 +0100, dinkypumpkin wrote:
>> On 08/08/2011 11:47, David Woodhouse wrote:
>> 1. It means the installer would always have to be built on Windows
>
> Why so? Doesn't it work in wine?

Dunno - haven't touched Wine in aeons.  Strictly speaking, I think you 
only need to run pp on Windows since NSIS can build the installer on 
Linux/OSX.  If Strawberry Perl and related gubbins work in Wine, then 
it's all good.  I've created build scripts such that the Perl support 
can be built separately when needed.

>> 3. So if I upgrade the version of Perl, I'd like to go to 5.12.  If
>> anyone thinks there is a reason to only go to 5.10.1 instead, chime in here.
>
> Might as well update to 5.12, I think. Why stay on something older?

5.12 it is then.

>> This will require some thought.  In the current installer, only rtmpdump
>> uses the redirects set up at infradead.org, and changing them now would
>
> More trouble than it's worth, I suspect.

Well, I still think it would be worthwhile to use the system of CGI 
redirects.  It would be nice not to have to go through the rigmarole of 
posting a new installer just because a URL has changed.  Even if it only 
amounts to changing a string, it means someone has to sit down, do a 
build, post it, etc.  The current installer can't use the redirect 
system because of its hard-wired assumptions about archive structure, 
etc.  However, my new installer can.

I finally had a chance to spend some more time looking at this, and I 
think it's simpler than I first thought.  Here's how I think it could work:

The CGI redirect system responds to at least these keys:

mplayer   - mplayer archive
lame      - lame archive
ffmpeg    - ffmpeg archive
vlc       - vlc archive
rtmpdump  - rtmpdump .exe
rtmpdumpz - rtmpdump archive

Unless the current installer was built with code other than that in the 
git repo, it only uses the "rtmpdumpz" key - the rest are hard-coded in 
the installer script.  That means that we could bring a new installer 
online simply by changing the configuration for all the other keys to 
point to the new archive URLs, and adding a new one for "atomicparsley". 
That way the new and old installers wouldn't collide, and it would 
presumably not require much work on the server side.  I'm assuming it's 
your server-side code, so you're the ultimate arbiter on this.

> I think the main reason for the redirects originally was not so that it
> could adapt to new versions of tools, but more that it could adapt if
> the external URLs stopped working; it could be pointed to another mirror
> or something.
>
> If we're pointing at stable download locations, we should be fine.

I would think the new URLs are reasonably stable, but only 2 of the 6 
helper apps come from what I would call primary sources, so who can 
really say?  There might some small improvements we could make (see post 
from Nick Ludlam elsewhere in this thread), but I think the 
infrastructure already set up at infradead.org is probably OK for 
distributing updates for this kind of project.  If we get the installer 
updated to use it effectively, then it means that as long as 
infradead.org is running, we can get updates out for both get_iplayer 
and its dependencies.