RE: $HOME/.Nooooooo!

From: Mark Taylor <m.b.taylor-at-bristol.ac.uk>
Date: Tue, 13 Feb 2007 18:26:38 +0000 (GMT)


On Tue, 13 Feb 2007, Tony Linde wrote:

> Hi Pierre,
>
> I can certainly understand the reasoning but would like to find a solution
> to the problems it causes.
>
> Maybe a $HOME/.ivoa directory and all VObs apps place their own profile and
> other data underneath that (so, $HOME/.ivoa/aladin) - *providing* we can
> find some way in a windows machine over which the user has no admin
> privileges to redirect that directory to some other place.
>
> Any ideas anyone?

In my opinion, the java.io.tmpdir system property provides the best place for java applications to put _temporary_ files, that is ones which do not need to persist between invocations of the application. I haven't checked it on all possible OSs, but as far as I know it resolves to somewhere sensible (C:\Documents and Settings\name\Local Settings\Temp, C:\TEMP, /tmp) on all reasonable platforms.

As per my previous message the value of this system property (location of the temp directory) can be overridden at run time if you have control over how the JVM is started. This is true if you are running applications from the command line, though I'm not sure about useful ways of configuring your machine to run webstartable applications with customised system properties (you can fix the JNLP file, but that's not ideal).

For files which need to persist between application invocations, java.io.tmpdir is not suitable. For small configuration files such as .plastic, I would argue that the user's home directory (java user.home system property, probably the same as the HOME environment variable) is a good place for this (I don't see anything to be gained by using $HOME/.ivoa/appname rather than $HOME/.appname). I don't believe it is the responsibility of application authors to jump through hoops to cover the case in which there is not space to write a few kilobytes in the user's home directory - the user or admin ought to clear it up.

The only remaining problem for java applications is if they need to persist large (multi-megabyte?) amounts of data between sessions. In this case applications will have to make their own decisions: some possibilities are asking the user where to save things, having a configuration file, or using a well-known location which the user can set up as a link to a chosen location.

Non-java applications will have somewhat different issues of platform dependency, but they tend to be more used to platformdependent  solutions in any case.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
Received on 2007-02-13Z19:27:01