Get Iplayer for Windows

[dinkypumpkin]

On 15/08/2011 17:58, Jon Davies wrote:
>> On Sun, 2011-08-14 at 17:41 +0100, Jon Davies wrote:
> Ah, there are two aspects to this:
> 1. why not distribute the whole of strawberry perl?  for which the
> answer is that a minimal subset is smaller and can be built such that
> it includes non-standard packages, which is useful, and to support
> dinkypumpkin's new tagging stuff necessary. (though by the time you
> add the extra packages from CPAN to support tagging and some other
> features that have recently crept into versions of get_iplayer, it's
> not hugely smaller.)

The tagging-related modules don't add that much, and PAR::Packer adds 
all the core libraries anyway, so nothing we do will have a huge effect. 
  Moving to Perl 5.12 will bulk things up quite a bit just by dint of 
more stuff being in core.  Even so, David's 10-1 ratio still roughly 
holds if you compare the disk usage of the get_iplayer Perl package to 
the MSI install of Strawberry Perl.  I would hazard a guess that most 
people who want get_iplayer on Windows aren't necessarily interested in 
taking the full Perl plunge.

I can see how it might be nice to just download and run the Strawberry 
Perl installer and not need to manage Perl as a dependency.  Having the 
ability to add extra modules is nice, but I wonder how useful that will 
be.  So far, the only modules not already provided by Strawberry Perl 
5.12 are the 3 needed for MP3 tagging.  We could cover that tagging 
functionality, albeit not as well, by providing a windows build of id3v2 
for download, or embedded in the installer (this is what I was doing in 
my builds).

I'm playing a bit of the devil's advocate here.   I expect there would 
be potential headaches with relying on an external Perl.  If there 
really were new features that needed extra modules, we couldn't control 
the update process, and users might find themselves at the mercy of 
broken installations, etc.  On balance, I think it's worth continuing to 
own the Perl used for get_iplayer.  Now that I've automated the process 
of producing the Perl component and installer, it shouldn't be too 
difficult to do so.

> 2. why not make the packaged version of perl a downloadable component?
>   if we're making the other dependencies updatable components, then it
> would make sense to make the perl distribution an updatable component
> as well, which would allow us to update perl without building an
> entire installer.  By extension, the windows scripts should be a
> downloadable component too, so that they too can be updated in the
> same way.  But this doesn't have to be done in one go.

That wouldn't be difficult if somebody wants to host the Perl component. 
  The zip extractor plugin is already in the installer.  My earlier 
installer versions included the Perl bits as a zip file (one less step 
during the build), and it's easy enough to extract it as needed, just 
like the helper apps.  I've reverted that for public use since the zip 
archive really bulks up the installer (archive doesn't compress much). 
Still, it would be simple enough to treat the Perl components and 
scripts just as helper apps.  That said, those aren't particularly 
volatile components.  Since the installer can already find new versions 
of itself, it is probably just as easy to distribute Perl in that form.

>>> I have an objection in principle to install/update functionality that
>>> depends on the server behaving in a particular way because it ties you
>>> to servers that can be specifically configured, which rules out many
>>> hosting services - so using server-side redirects somewhat irks me.
>>
>> I'm not sure that's a consideration. We're pointing it at our *own*
>> service which *is* under our control.

In general, I came around to the viewpoint David expressed.  However, I 
wouldn't mind simplifying things a bit in order to minimise the reliance 
on a specific backend configuration and to future-proof the installer a 
bit.  My thought is that we would incorporate all the installer 
configuration data - component versions, download URLs, etc. - into a 
simple INI file (easy to handle in NSIS script).  Whenever the installer 
fires up, instead of doing the online version check it does now, it 
would pull down the file, check for changes, and act appropriately.  We 
could reduce the number of online update resources from 8 to 1, and a 
simple file could be hosted anywhere.  We might even bake in a backup 
source like a Google Code site or similar.  I'm happy to do that or 
something similar, but I'm not sure it's worth making such a big change 
now. I reckon a new release of get_iplayer plus installer with the 
current CGI redirect setup will hold people for a while.

>> I can even put the get_iplayer.cgi
>> script from http://www.infradead.org/cgi-bin/get_iplayer.cgi into the
>> git repository.
>
> since it's now an integral part of the installer/updater, this would make sense.

I second that.  I could possibly save you a bit of typing by making 
updates for the new release.