For Linux -- why not just use the current working directory as a default? I don't think there is any universal place I've ever seen to cache files like that.
On Windows, I'd like the option to choose where to save those cached files. I install most of my apps on my SSD, but given the option, I tend to store files and cache on my HD drive to save space. I imagine I'm not alone in that regard. It can be a default to store it in the non-roaming app-data folder on Windows (in the downloads directory on the mac?). -Nick On Mon, Jan 27, 2014 at 5:50 PM, OmPrakash Muppirala <bigosma...@gmail.com>wrote: > On Mon, Jan 27, 2014 at 2:35 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > On 1/27/14 2:24 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > > > > >On Mon, Jan 27, 2014 at 1:09 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > >> > > >> > > >> On 1/27/14 12:37 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> > > wrote: > > >> > > >> >On Mon, Jan 27, 2014 at 12:33 PM, Alex Harui <aha...@adobe.com> > wrote: > > >> > > > >> >> Justin suggested that the installer should save downloads in a > > >>central > > >> >> location on the users computer so that if multiple SDKs are > installed > > >> >>that > > >> >> use, for instance, the huge AIR SDK, it only gets downloaded once. > > >> >> > > >> >> > > >> >As a developer/architect, I would prefer to have control over where > the > > >> >SDKs are stored. How about prompting the user to select this folder > > >> >first? If user chooses to skip this, we would simply download the > SDKs > > >> >every time. > > >> First, let me make sure I was clear. This is about where to store a > > >> downloaded compressed artifact, not where we expand it. For example, > > >> where we would store AdobeAIRSDK.tbz since it gets downloaded and > > >>expanded > > >> by both the Flex SDK and FlexJS SDK. I don't think we can control > where > > >> we store and shore a single uncompressed AdobeAIRSDK because the IDEs > > >>are > > >> expecting those files in the installation folder. > > >> We could have folks choose the folder, but it would be nice if the ant > > >> scripts can also leverage a central repository of compressed files > > >>without > > >> having to prompt the user from the command line. > > >> > > >> > > > > > >Yes, got it. What I am proposing is to prompt the user to point to a > 'AIR > > >SDK.zip, etc. storage cache' that we will reuse from. This prompt will > be > > >shown only the first time which the user can chose to ignore. In that > > >case, we will download artifacts to <installation_dir>/temp and delete > the > > >temp directory later. But if the user does select a 'storage cache', we > > >will use that to store downloaded artifacts. On subsequent installs, > the > > >Installer will look at the cache and if nothing is found, it would > > >download > > >it via the net. > > > > > We can certainly do that. I was just hoping for a less interactive > > solution. I just checked in the ant scripts for the main Flex SDK that > > the new installer will use (once the jenkins server generates new release > > artifacts). I'm still not clear on what kinds of installers we will > offer > > to our Linux users. I think there are some issues on Linux and some > other > > non-Linux places about requiring the installation of the AIR runtime in > > order to run the installer. One of the benefits of the ant scripts is > > that I think it gives the Linux user a choice. They can either install > > AIR and run the installer, or download the binary kit, expand it, and run > > ant -f installer.xml if they have Ant installed. So I was hoping a pure > > Ant install could also find/use this cache of downloads. > > > > Thoughts? > > -Alex > > > > > I see your point. I would think that Linux users would be more comfortable > just installing via ant. Maybe default the paths of cache directories when > installing via ant? > > When installing via the Installer, we could still have defaults, but still > let users change it? > When you said that "We could use the application storage folder in AIR, but > that's hard to find and clean out.", did you mean manually cleaning it > out? I dont think it is that hard to find the app storage directores via > code or manually. We could perhaps default to that? >
