locked
architectural discussion: options / settings storage RRS feed

  • Question

  • I've been thinking about the upcoming daunting task of porting a whole bunch of server apps of mine to be Add-Ins.  Typically, these use the Windows Registry to store application settings, which is quite common among servers written specifically for Windows.  Esepcially for those that were written before wide-spread use of XML.

     

    However, I started thinking more about this.  With the Application Folder available, is the registry really the best place to store these settings, even though doing so is quite common? 

     

    The facts:

     

    - Lack of system partition or primary data redundancy necessitates full system Reinstall in several scenarios

    - Add-Ins must be reinstalled if the system is reinstalled

    - The registry is wiped during reinstall

    - Power Pack 1 adds the ability to backup Application Folders natively in WHS

     

    The combination of the above leads me to the conclusion that XML or INI files stored in the Applicaiton Folder would be a far better solution that using the Registry to store settings.  Granted, today this is not a good idea with the corruption issue.  But, arhitecturally speaking, as well as based on what is in the SDK, it seems clear that this sort of thing is exactly what the designers intended, and if it were safe to us the Application Folder, most if not all Add-Ins should be. 

     

    Given the limited restoration options, the Registry seems like the worst possible choice for storing settings.

     

    In fact, it seems very approprite that every single bit of data, from settings to application data to log files, for the Add-In and it's associated server all fell within it's Application Folder.  That way restoring the add-in is as simple as:

     

    - restoring Application Folders

    - dropping the msi into the add-in folder

     

    Upon first run, the add-in should read everything just as it was left, and wouldn't even know it was uninstalled / reinstalled.

     

    It really is too bad that the current corruptoin bugs exist, as it seems to me that in an ideal world, all Add-Ins would follow this simple model.  It makes restoration after a WHS reinstallation a total piece of cake.  You simply restore your Application Folders (PP1 feature), and then drop in all of your Add-In deployable MSI's, and you are up and running.  No reconfiguration.  No application-specific backups.  It just works.

     

    Anybody have any thoughts on this?  Am I overlooking something obvious?

     

    - Ryan

    Wednesday, February 6, 2008 9:52 PM

All replies

  • Application folders become even more desireable because you can set the "isreliable" flag and have your settings duplicated.

     

    I think what you're describing is exactly what MS had in mind for application folders.

    Friday, February 8, 2008 9:11 AM
    Moderator
  • I'm sure one of the uses Microsoft envisioned for application folders is storing persistent application data, too. However, right now the file corruption issue detailed in KB946676 argues against doing so, as application folders take part in the Drive Extender/storage pool environment, and files stored in an application folder would therefore be subject to the same corruption.
    Friday, February 8, 2008 4:38 PM
    Moderator
  • Re: Sam: I'm glad to see we agree. ;-)  That's a great point about the duplication.  Yet another reason to use that instead.

     

    Re: Ken: Yep, it's too bad. ;-(

     

    Even with the corruption issue preventing use of Application Foldres today, I would still recommend against using the registry to store any settings for an add-in.  It will simply be harder to port later once the Application Folders are working correctly.  An XML file is an XML file, whether sitting in Application Folder, or D:\<your specific folder today>.

     

    That's how I'm going to handle mine.  And later, once DE is working corectly, I can release an updated Add-In that, upon seeing that the Applicatoin Folder doesn't exist, after creating it can look for it's data in the previous directory, and migrate it.  Or, the entire migration could be handled as a custom action in the installation of the add-in.

     

    - Ryan

    Friday, February 8, 2008 6:46 PM
  • I think it depends on the nature of the data you're storing. In my case, it's just settings; the worst that could happen is that someone needs to rebuild their server diagram.

     

    Is this historical data you're storing, ryan? Stuff you'll need to keep and refer back to for your add-in?

     

    Friday, February 8, 2008 7:52 PM
    Moderator
  • Nope, I'm just talking about settings at this point.  It's not "hard" to reconfigure; just a pain.  Like you said, the worst case is they have to reconfigure the settings dialog.  A few minutes work.  But if they have to do that for every one of a dozen add-ins, it would have been nice if the plug-ins all had their settings restored when the Application Folder was restored.  In my case, I'm looking at 5 add-ins in this suite alone, not counting what others may be installed that I don't have control over.

     

    There would be data as well, but that's a separate discussion.  In some cases (but not all), the data would itself be stored on the server shares, so I also have to wait for the DE corruption issue to be addressed as well (or limit my first deliverables to fully-populated data pool D: only sitting on RAID array).

     

    Ryan

     

    Friday, February 8, 2008 10:58 PM