[Gvsig_english] Recent change for gvSIG 1.10 in SVN

[Benjamin Ducke]

I agree that this needs a lot more planning.
Versioned configuration files are a complex matter.

But the current patch is highly problematic and
radically changes behavior in a release candidate(!).

So could we please undo it and have gvSIG 1.10
behave exactly like 1.9 did?

Cheers,

Ben

----- Original Message -----
> Hi Ben,
> 
> It seems that commit matches the following ticket:
> http://forge.osor.eu/tracker/?func=detail&atid=732&aid=14411&group_id=89
> 
> I think the idea was allowing different configurations for different
> gvSIG installations.
> However, I agree with you that it is not as good ideas as it may seem
> at a first glance, and I suggest to better analyze all the possible
> behaviours to select the desired one.
> 
> Besides the multi-user problem that you point at, I see other possible
> problems: - If I install a new gvSIG version, should I set all my
> configuration again? This looks as a regression to me.
> - What happens if the user has no write permissions on the gvSIG
> installation folder?
> 
> I think it is ALWAYS a good practice to keep program configurations on
> the user home, and program installation on a different one, and don't
> mix them up.
> 
> I guess that the intention of this change was to be able to execute 2
> different gvSIG versions which may have conflicting configuration
> files (because changes on code, etc). If this is the case, I would
> suggest a different approach:
> - Keep config in home.dir folder, under a versioned folder (for
> example, ${HOME}/gvSIG/1.1 or ${HOME}/gvSIG/1.9).
> - Whenever you install a newer version, copy the last version
> configuration to the new dir. For example, if you new install 1.10,
> copy config from ${HOME}/gvSIG/1.9 to ${HOME}/gvSIG/1.10 and update
> any conflicting files on 1.10 folder.
> - In this way, the user would find the old configuration in the new
> versions, but version conflicts are avoided (so he would still be able
> to run 1.9 if desired)
> - Drawbacks: configuration changes applied on 1.9 version wouldn't
> apply to 1.10 version and vice versa. But this is better than having
> version conflicts, I think. Of course it could be solved with smarter
> approaches, but for sure they would be more complex and I don't think
> there are resources available for this now.
> 
> I have written all this off the top of my head, but I think this topic
> should be carefully thinking, as it may create lots of problems
> otherwise.
> 
> Best regards,
> 
> César
> 
> 
> 2010/7/7 Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk>:
> > Hi all,
> >
> > I have just had a look at the recent changes in SVN and found
> > that the default location for gvSIG settings has been changed
> > from $HOME/gvSIG:
> >
> > Launcher.java now has this:
> >
> >  andamiConfigPath = System.getProperty("user.dir") + File.separator
> >  + "andami-config.xml";
> >  pluginsPersistencePath = System.getProperty("user.dir") +
> >  File.separator + "plugins-persistence.xml";
> >
> > Are you all sure this is a good idea? According to the Java
> > documentation, "user.dir" is the "current working directory".
> >
> > But:
> >
> > 1. If the user launches gvSIG from a shell, then "user.dir" could
> > be literally ANY location in the filesystem. So settings are bound
> > to get lost between sessions or (even worse) they get restored from
> > unexpected old storage locations.
> >
> > 2. If the user launches gvSIG via a desktop shortcut or a Mac OS
> > App package, then "user.dir" will always point to the gvSIG
> > installation folder. On a system set up for multiple users, with
> > just one gvSIG
> > installation folder, this can mean total chaos, as users overwrite
> > each other's settings.
> >
> > All of that makes me a bit worried!
> > Could someone please explain the reasoning behind this change
> > and how it is supposed to work?
> >
> > I think the ONLY reasonable place for user settings has to be
> > the user's home folder. If it is required to keep more than one
> > set of settings, then those sets should all be kept in the home
> > folder, perhaps in separate directories.
> >
> > Cheers,
> >
> > Ben
> >
> >
> > ------ Files attached to this email may be in ISO 26300 format
> > (OASIS Open Document Format). If you have difficulty opening them,
> > please visit http://iso26300.info for more information.
> >
> > _______________________________________________ Gvsig_internacional
> > mailing list
> > Gvsig_internacional at listserv.gva.es
> > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
> >
> 
> 
> 
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> César Martínez Izquierdo
> GIS developer
> - - - - - - - - - - - - - - - - - - - -
> ETC-LUSI: http://etc-lusi.eionet.europa.eu/
> Universitat Autònoma de Barcelona (SPAIN)
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> _______________________________________________ Gvsig_internacional
> mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional


------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.