Windows installer musings

[Cantor, Scott]

While it's true that the alpha can run from the unpacked directory I don't
think that's our real goal, so I think we can assume both installers are
meant to create an install tree and copy files into it with the usual
protections. But note that conf/system is meant to be overwritten. We
could modify that by actually using hashes to detect changes and do an
RPM-style thing with the originals, but I don't see it as essential.

I have a slight preference for the distribution itself containing the
conf/ tree rather than renaming it something else. I think having it there
would be a good way to provide each version's default files in an obvious
place that mirrors the installed versions.

Regarding editing of files, my hope was that we'd probably generate or
update idp.properties via Java code since Java has support for property
set I/O.

As far as 2->3 upgrades are concerned, I tend to think that because
authenticaton is just not a match, any sort of automated upgrading is very
limited in scope and benefit. It was a nice dream to automate it, but I
think realistically that's going to be scaled back to making it simpler by
maybe generating services.xml for upgraded configurations and either
providing the list of files to copy into conf/ or actually doing it from
the installer if you install into a V2 tree. I think we should discuss
that specifically and see if we should start with Windows or not.

What I would like the upgrade to do is rename the existing conf to
conf.old or conf-v2 or whatever, and then selectively create or copy files
over into the new conf/

-- Scott