On 10/7/14, 11:09 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>> > Can we release the SDK, without simultaneously releasing the >>Installer? >> >> We can, but if people can't install it via the installer we're not going >> to see much adoption. >> > >My understanding was that Alex¹s work with Œant_on_air¹ removed the >release >dependency between the SDK and the Installer? Well, yes, technically it did. It made it possible for us to change many things about how an SDK install works without a second vote for the installer and requiring folks to upgrade the installer before installing the SDK. However, now when an install fails, you have to determine if it is an issue with the ³execution engine² in the Installer (i.e., ant_on_air), or in the script it is running. The problem we are having with certain SourceForge download URLs is an issue with the ant_on_air code. The SourceForge server no longer sees the request as a programmatic request and instead responds as if it is a browser. I spent the whole morning on it and was unable to customize (actually remove) certain headers that AIR puts in the request that I think are telling the server that we are a browser. Apache Ant can run the same Get task request successfully so we know it isn¹t a script error. A Charles Proxy session shows that AIR sticks additional headers in the request. That said, I think I have successfully implemented workarounds such that there is significantly less need to release the Installer, especially since we don¹t have a fix for this SourceForge issue. I¹d say we can just release the SDK without the Installer, but there might be some issue in that list that is more important than I currently think it is. -Alex
