Author Topic: Auto Updater: command line arguments  (Read 2178 times)

0 Members and 1 Guest are viewing this topic.

Offline ShdNx

  • Lead Developer
  • Lance Sergeant
  • *
  • Posts: 357
  • l33tp0intz: +27/-0
  • 0x2B || !0x2B
Auto Updater: command line arguments
« on: July 14, 2011, 05:07:33 PM »
I recall having somebody suggest that it would be handy if the Auto Updater's behavior could be controlled automatically, without requiring any user intervention. Because it's clearly not a feature the majority of the players would use, it has been given low priority, and have been neglected so far. Until now, when I feel like the Auto Updater is stable enough (as of the upcoming fix) that I can afford adding such a feature. However, I'm afraid I don't remember exactly who proposed or exactly what his proposal covered, which led me to open this topic where you can voice your opinions in the matter. What would you like to have? What would you use it for?

My idea is that the application would accept a set of command line arguments, with the following syntax:
MWLL.AutoUpdater.exe --dlPath=<downloadPath> --installPath=<installPath> -auto -autoshutdown

(I usually use the "--" prefix when it's a key=value argument, and the "-" prefix to indicate flags.)

--dlPath and --installPath would allow you to specify the download directory and the installation directory, respectively. Specifying the -autoshutdown flag would be effectively the same as checking the shutdown-when-completed checkbox on the updater window. Last, but not least, the -auto flag would instruct the application to do everything automatically: no user popups, no waiting for user interaction. This could also completely prevent the program from rendering a GUI, or make it send output to the console instead.
The former (GUI is displayed, but no user interaction is expected) would be the easiest, but I'm also willing to make it that no GUI is rendered whatsoever, or that a console is used. Just let me know if that would be better, and why.
When it came to decision making, the application would automatically choose the safest solution, for example, it would not delete the old MWLL build.

Implementing this would certainly mess things up, but I'm willing to do that if there's really demand for it.
So, what are your thoughts? How would you like this work? When would you use it?

Thank you all very much in advance for your input!
External tools lead developer

Klingon Programmer:
What is this talk of release? Klingons do not release software. Our software escapes leaving a bloody trail of designers and quality assurance people in its wake.