[rfc][icedtea-web] fix for RH947647, following the XDG basedir specification

[Jiri Vanek]

On 05/21/2013 03:38 AM, Omair Majid wrote:
> Hi Jiri,
>
> On 05/20/2013 03:11 PM, Jiri Vanek wrote:
>> This fix is migrating us to  ~/.config/icedtea and ~/.cache/icedtea
>> instead of ~/.icedtea.

Hello Omair! Thank you very much for feedback. Thou you have unwillingly fell into endless discussion :)
//which hopefully will lead to best solution ;)
>
> We decided on the current paths (and files and formats) to stay as close
> to the proprietary JREs as possible. We have deviated from this in the

I was not aware of this, but maybe there is time to revalidate.
  - What benefits we have from keeping the like-proprietary plugin structure?
    - Are we still close enough to it?
  - What benefits we can have fro moving to new one?
    - and how to achieve this painlessly...


So my answers:
   - none
     - have no idea ;)
   - All our main "customers" are using the XDG and bug have been already filled - 
https://bugzilla.redhat.com/show_bug.cgi?id=947647#c4 - is explaining more deeply (second link)
TBH - I liked the old structure :)

note - I do not insist on this patch. It was proposed to 1.5  - 
http://icedtea.classpath.org/wiki/IcedTea-Web#IcedTea-Web_1.5   - and Deepak Agreed  - but this can 
be of ocurse reverted - as I noted, I do not insists.
   - I have hard-coded the paths -  It was because of my ideas appeared to be in dead end, and so in 
good condition to initialise the patch
    Can we support both, or at  least "both" ?
    Need to support the 1.4  and older is a msut of course.

> past (the contents of the cache directory, for example), but it's either
> because of something not (yet) implemented in icedtea-web, or something
> the user should never have to care about (like cache directory layout).
>
> I am not sure if that decision was perfect, but if we are going to
> change this now, I would like us to weigh all the pros and cons.
>
> As far as the patch itself goes, two things jump out to me:
>
> 1. We need to stay backwards compatible, if possible. For things like
> configuration files, we should check the old locations too. For the
> persistence cache, not reading the old data is like throwing away user's
> data.

ouch. 99% of this patch is focussed on backward compatibility. see the 
move14AndOlderFilesTo15Structure() method (and its usages)! And launchers....

>
> 2. The patch seems to be missing support for using the environment
> variables (such as $XDG_CONFIG_DIRS) to specify the locations of the
> directories.

Yes, this was intentional. It will need more tuning and more adaptations.

Currently there are specified relative paths :
$XDG_DATA_HOME  -user-specific data files
$XDG_CONFIG_HOME - user-specific configuration
$XDG_CACHE_HOME - There is a single base directory relative to which user-specific non-essential 
(cached) data should be written.
$XDG_RUNTIME_DIR -  user-specific runtime files and other file

Fromthose I have used
$XDG_CONFIG_HOME - for deployment.properties(.old), security and .appletTrustSettings and log
$XDG_CACHE_HOME - for cache, tmp and pcache (persistence)

Some of them are worthy to other XDG, but I'm not fan of such a crumble [rfc] ?


Some more thoughts about this:
  - eg I have non XDG variable set, but many applications have already started to use theirs default 
values.

- If we decide to move to ./config and ./cache:
    if used XDG* variables are set, then use them. otherwise use ./config and ./cache
    if they change, user is on his own?

- If we decide to not to move to ./config and ./cache:
    if used XDG* variables are set, then use them. otherwise use ./icedtea
    if they change, user is on his own?

- how about xdg not following systems (windows) ? Keep .icedtea or move to ./config and ./cache ?


Thanx for any hints


J.