ISSUE:
I have been giving some thought as to how an enterprise can have packages where the main application doesn't update very often, but IT needs to apply updates settings or data on a constant basis, possibly monthly, weekly, or daily. Quite often there is a back end service also involved in these updates, and the client piece must be kept in lockstep.
This proposal is an opining salvo; I have no intent to start on these proposed changes any time soon. But we need to start thinking about ways in which to better handle the enterprise need around this.
The proposal here is narrow - involving only the update of settings and data files, and not of updating the application executable bits.
EXISTING OPTION:
One option available today would be to organize the main package so such files are referenced using VFS pathing within the package, and then create and distribute a modification package with the update and having the management automation remove the old modification package, if present. Versioning on the modification package might actually do that for us automatically, but that would need to be tested. The proposed goal is to eliminate the need to constantly package the changes.
PROPOSED OPTION:
This proposal would involve updates to the Package Support Framework PsfLauncher, and a new fixup shim (or integration into the existing FileRedirectionFixup).
The idea is to support the ability for the IT organization to update settings and data files using a technique very similar to what they often do today: utilize a server share, applying the updated files when needed to the files in this share. This could mean overwriting the existing server share files, or using directory naming under the share that forms a version numbering system allowing the new data files to be added to new folders. Such a share would be constructed as read-only for user accounts associated with the application.
There is a need to support two methods:
- Replication: Replicate the latest files to the client locally upon launch. The PsfLauncher would be instructed (via new entries in the json.config) to detect and copy the new files. This would be handled at launch time, potentially slowing down that launch depending on the size of data to be downloaded. The launcher would copy the necessary files into the per-user-per-package redirection area under the appropriate WritablePackageRoot\VFS folder.
- Redirection: Redirect appropriate file requests to the share at runtime. The Psf Fixup dll (new or enhanced existing one) would intercept individual file I/O requests and when they match the regex pattern of the fixup configuration re-direct the request to the configured share location. This does not slow down the launch, but potentially might be sub-optimal for accessing large files over a high-latency connection to the share.
For both scenarios, it would be highly advantageous for the JSON file itself to be located in a VFS path rather than the root folder. In repackaging with the PSF and PsfTooling, we routinely work this way all the time and it works very well; software vendors creating their own package tend not to work this way, so additional instructions for them would be needed. The reason for this is that we would want the location of the server share to be indicated in the JSON file. If the JSON file is located in the main package in a VFS folder, then it is possible for the vendor to supply a valid JSON file with a placeholder for the server share and have the customer create a modification package (once) to replace the JSON file with their own.
There are plenty of options on how a solution to this problem could be implemented. I am not suggesting that this is the only, or the best, solution. I do, however, want to start the conversation now so that the community can provide input. The reply button is just a click away!
Tim
