Yes it would be. Why? Because mushclient is a 'single' application with the only DLL it uses that I am aware of being the spell checker. I am not even sure that is a DLL, since I haven't looked.
Even ones that use different DLLs to impliment features, cannot simply install and continue running, they have to shutdown. There are two reasons for this.
1) Not all dlls may be loaded in memory at once and the 'new' ones when loaded may not be compatible with the 'old' version. In fact there is 100% certainty they won't be, since they are statistically linked. In other words, the old program will expect Output.dll to have the Note command at the 2350th byte into the file, but the new one compiled with it at say the 2356th byte. Oops. The moment the program loaded the dll and attempted to execute the call *CRASH*.
2. The currently loaded version won't be able to use all the features of the new version until loaded, even if you assume that the first problem is somehow solved. Some dumb user could leave the program running 24-7 and wonder why it doesn't suddenly provide the new features.
About the only things that do keep running are virus scanners. They manage it because they just reload the database, but when ever one needs to install an updated engine, then it also requires a restart (or even a reboot).
*Huge* systems like Windows itself get by with this because most of the time the stuff you are patching is 1-2 dlls that are not even loaded. Major changes to IE and other "integrated" things always require a system reboot of some sort, other things get patched and then run without any problem, since the programs just load the new ActiveX component. This is also however one reason Windows is so much slower than other OS, since ActiveX takes extra time to load, send and recieve data. This is due to the fact that it is dynamically linked, making it easy to drop a new version into place without recompiling everything on the machine, but every request has to go through the OS. Statistically linked dlls are loaded and called directly.
So, 1) mushclient would run like zMud if it got chopped up into easilly updated bits and 2) it is way too small for this to be a major benefit for updating. More likely if such an option was added, it would follow the same sort of thing as GetRight or other small programs, that tell you on the first screen of the installer, "Make sure all copies of MUSHclient are closed before starting the install." It won't happen in the background.
----
Now ironically with plugins... A person could make a plugin that used and FTP client to check for a more recent version and automatically download the new copy and install itself. This would require that all 'current' data in the plugin be stored in a state file before the reload. It also means that you need an FTP client or small application that can check on the file version periodically, without hanging the client. You can code FTP into the client in scripts using Windows ComCtl, but that lags the script during the 2-3 seconds it takes to send a request, have the server respond and data to transfer. Just loading the HTML from a web page to check the status off the mud I play on at a voting site caused 2-3 seconds of lag each time.
So, auto-update Mushclient in the background - NO
Auto-update a plugin - YES (in theory) |