$HOME/.Nooooooo!

Mark Taylor m.b.taylor at bristol.ac.uk
Tue Feb 13 10:26:38 PST 2007


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 platform-
dependent solutions in any case.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/



More information about the apps mailing list