Windows installer musings

[Rod Widdowson]

> 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.

Good.  That’s the intention of the Windows installer (of course the unpacked
distribution will not be visible except for admin installs)

> But note that conf/system is meant to be overwritten. 

I'd sooner say replaced.  We do not want old files to survive an upgrade
(say that "system\flows\mumble.xml" turns into "system\flows\bumble.xml" -
we do not want the old mumble flow to stay around.

A nice trick with Windows Installation is that it will only delete files it
installed - so in the above case "flows\mumble.xml" will be removed, but if
the admin had added something there it would remain (of course all their
mainstream changes will be hosed, but that’s their problem).  I'm going to
leverage this for the conf directory in the same way as the SP does - if we
copy the files manually during install then a subsequent uninstall doesn't
remove them and so they are there waiting for the next install.

> 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.

No - I see no benefit in all the "save time by making things more
complicated" approach - it would save milliseconds on the install.  Hence
why I don't care about the use of heat forcing us into the "uninstall-old,
install-new" approach. 

> I have a slight preference for the distribution itself containing the
> conf/ tree rather than renaming it something else. 

Works for me.  I'll make the installer put that "somewhere appropriate"
(just like we do for the SP) and then conditional copy into the final
location.

> 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.

That was mine - but I am concerned that we may lose all those useful
comments.  I haven't looked at the Properties API yet so it may be OK>
Otherwise we need to find a way to propagate the comments.

Of course if we need to edit xml files (something I want to avoid) we *do*
preserve comments.

 > 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.

OK.  When I get there I'll open a thread about it.
 
> 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/

That I'd like - I hope I can pull it off..
/R