Since we're upping the protocol version, we can do all this too at the
same time. So v2 digest will use SHA256, sign using SHA256withRSA and
will include the contents of META-INF in the digests. Upgrades++!
This also includes the code from pull request #73 to allow a .crt file
to be included with the app to allow for signature verification of
standalone apps (we already did this for applets via the applet
parameters).
Right now there's only two versions of the digester protocol, so I just
always generate both of them. If we evolve the protocol further, we
could conceivably allow you to specify a "minimum" protocol version,
once you were confident that all of your clients had upgraded to a
version of Getdown that used that minimum version.
The one major change here is that Getdown.isUpdateAvailable/install()
are no longer static.
GetdownApp has a start() method that you can call if you want to get the
Getdown reference back. You can call isUpdateAvailable() on that. It was
super weird that you would call GetdownApp.main() and then just call
some static methods after that.
Whenever 'use_code_cache' is set to 'true' the application's code
resources are copied to a cache directory prior to launching the
application. This is done in order to support multiple open application
instances of different versions.
The "Trusted-Library" manifest attribute is required for Applets and
Java Web Start. Otherwise classes from the Getdown package might be
silently ignored (ClassNotFoundException).
1) Download resources first into a temporary file
2) Perform verification and digest comparison with the downloaded
temporary file instead of the original if temporary file exist
3) Only when verification completes successfully rename all the
temporary files to override the original. This step can be done
automatically or manually by calling GetDown.install() which is useful
for those who want to download in background and install upon program
exit.
These can appear anywhere %APPDIR% and %VERSION% substitutions occur (pretty
much everywhere in getdown.txt).
In this case the NAME is the name of an environment variable, and the value of
the environment variable is substituted into the text.
This makes sense given that we already support app_id-prefixed apparg
parameters, and one might want to configure the JVM specially for different
apps from the same installation.
Note: unlike apparg, app_id-prefixed jvmargs are appended to un-prefixed
jvmargs rather than replacing them. I think this makes sense because you
probably want to specify standard JVM args and then maybe tweak a thing or two
for your other app. This is also backward compatible which is usually a good
thing. It does mean that it's harder to "undo" a jvmarg set for your "default"
app, in such cases you'd probably have to not have a default app and instead
identify all of your apps with app_ids.
Michael Bayne