Installer

[pR0Ps 0]

I heard that the ApexDC++ team was thinking of allowing a config file to be bundled with the installer.

I think this is a great idea as it allows hubowners to pre-configure Apex to connect to their hub with all the settings they want (or don't) already configured.

A few ways of doing this were being tossed around, including looking for a config file in the same directory as the installer and allowing the user to import a config file into the installer.

I was thinking that another good way of doing this would be to include an optional command line switch that would tell the installer to use a config file at a URL specified (EX: /useconfig http://blah.com/blah.xml)

The Apex toolbar/OpenCandy/Conduit stuff would all still be displayed.

Just another way of allowing hub-owners to pre-configure clients without tampering with the installer.

Thoughts?

[Mek 13]

I have pre-configured the Slim version by including a DcPlusPlus.xml file and it works for our users. The problem is that, when upgrading, many of the users use the official installer and then the settings get messed up (like they are in AppData and not in Apex folder, or vice-versa, I don't know...).

[Lee 84]

I heard that the ApexDC++ team was thinking of allowing a config file to be bundled with the installer.

Leaks! All lies!

How would you specify that URL pR0Ps? It needs to be easy for your users to set the config file and let Apex to the rest. The new installer already has the ability to download from a URL, so what about if you get user's to paste the config file or URL into the installer when it asks?

Mek: We understand that upgrading is a little painful sometimes and we plan to address this. Firstly, the AppData setting needs rewording so people actually know what it does. Secondly, it should backup the existing Settings just in case. Thirdly, detect where the current settings are and use that when upgrading.

[pR0Ps 0]

How would you specify that URL pR0Ps? It needs to be easy for your users to set the config file and let Apex to the rest. The new installer already has the ability to download from a URL, so what about if you get user's to paste the config file or URL into the installer when it asks?

I would give an option to specify the URL of the config file in the installer, but leave the option to automatically use a certain config file specified by a command line switch. The reason for this being that an install process should be as easy and as dumbed down as possible. Having to paste a URL into the installer would (sad as it is) be confusing for some (Especially the ones that just power though every install without reading anything). If a command line switch was introduced into the installer it would make it easy to package the installer into an executable archive that would extract the installer and run it, specifying the correct config file path. After that, updates would proceed as normal.

This switch would have no impact on the program at all if the switch wasn't specified.

Ex: If the installer was run normally, it would ask for an (optional) config file to use. If the installer was run as "Apex_Installer.exe /useconfig http://blah.com/config.xml" then (if the file existed and was a valid config file) it wouldn't prompt the user to enter a config file and use the one at the specified URL.

As an aside, one direction that I would like to see more installers go in is the thin installer. A thin installer is basically just an application that runs, looks for latest version of the program, downloads it, and installs it. It ensures that every user is always installing the latest version. Also, if Apex used a thin installer, by copying the installer to the install directory, it would make bringing back the old update feature a snap. When the user clicks the update button, it could just execute the thin installer and install the update, no need to open the web browser and download a separate installer. Plus, hubowners would never have to update their download links or anything on their individual sites. Point users to the thin installer and be done with it. Couple that with the option to specify a config file via a command line switch to the thin installer and it would be the perfect setup.

Just my 2 cents :)

[Lee 84]

Having hub owners packaging the installer up for users to extract is not an improvement on the situation now. Yeah they might be preconfigured but we want hub owners to point their users to our download page and use their configuration file.

The installer can already check for the latest version and download that instead, but we don't use it. When a new version comes out, 95% of downloads are of the latest version. I do agree that having the auto update was much easier for users, but it caused our web traffic to dramatically decrease and we are still working on a solution for this in 2.0. The thin installer approach is pretty much just unpacking the slim archive though, so I don't think we should do another installer.

Would your users not be able to import the configuration file you supply? If on the first page it supplies clear instructions and states "We have detected a configuration file in the same directory as the installer. Would you like us to import this configuration into the program?" or "Please select a configuration file (DCPlusPlus.xml) to import your settings" if no file is available. We could go as far as getting the user to select from a drop down list of hubs that you guys have supplied config for.

[alexistukov 0]

I co-admin our hub with pR0Ps. Here's a proposal for how we can meet the goals of both sides:

ApexDC++ Goal: Get users to their download page

Hub Goal: Make the install process as easy as possible for the users.

The best way to make the install process easy is for the installer and configuration file to be bundled together in one download (i.e. zip archive). The installer would automatically search for a configuration file in the same directory when launched. It then prompts the user if it should use the file, defaulting to Yes.

The problem with bundling a configuration file and installer is that it would be impractical for ApexDC++ to host many different packages with install files. An alternative to that, having each hub host their own package, doesn't get users to ApexDC++'s download page.

Here's a method that would fulfill the goals of both parties:

The ApexDC++ download page would accept a GET variable, allowing hubs linking to the download page to specify their particular installer/config package (through a number or short name). The download links on the page would then be altered to pre-approved URLs pointing to the installer/config packages hosted by that hub. There could be some visual indication that the user is downloading a hub-specific version (text or logo), but it's not necessary.

The approval process could work in many ways, one such way could be approving a particular folder on the hub's website as a download directory, the ApexDC++ download page would then append a standard file name onto the folder path to complete the URL.

[Crise 26]

Very good suggestion, however, it is going to need some planning... security etc.

[Lee 84]

Very good suggestion, however, it is going to need some planning... security etc.

Security as in anybody with the referral link could land on that page and see sensitive information? There could be a simple guide that explains how to connect to the hub and what to do once they are in the hub. We could allow the hub owners to specify a referral site that we accept this request from, and all other requests point to our generic download page.

I believe the hub owners should make the decision on how much information is displayed on the download page. Also, they could specify a password or code for the user to enter upon reaching the page. Taking it to the next level - allow the hub owners to change this information on the fly, without us needing to manually do it.