Quoting Rickard Öberg <[email protected]>:
> On 2011-01-19 10.19, Paul Merlin wrote:
> > When you write "1=executing user", you mean "executing user home
> > directory" don't you ?
>
> Yes, correct, thanks for pointing that out. On Windows it is a bit more
> complicated as well, because it looks for the environment variable
> USERPROFILE first, and only if that is not available does it use
> "user.home".
Yes, been there, that's a little mess on its own.
> >> Does this reflect the defaults for the various OS's, as far as you know?
> >
> > There seems to be a difference between MacOS/Linux and Windows. On the
> > formers you store cache in the user directory but on the later in the
> > system temporary directory. Is this on purpose ?
>
> Is there a better place to put it on Windows? When I wrote these down I
> tried doing due diligence, but it's non-trivial to find out where apps
> are supposed to store data on the different platforms. Hence the
> question :-)
That's only gut feeling but I'd prefer to see application cache data in the
user
application directory instead of the system temporary directory. In my mind, an
application handle it's own cache. I believe Mozilla applications do it this
way
on Windows as on other OSes.
> >> If yes, the next step is to change the various libraries and extensions
> >> to use this when determining where to store data. Typically data should
> >> be stored in {data}/{service id}/ so that it's easy to figure out what
> >> goes where.
> >
> > This seems perfect for a desktop application but on servers you often
> > want to fine tune all this a bit more. Is there a way to override
> > programmaticaly, maybe at assembly time, each of the root directories ?
>
> The service looks up the FileConfiguration bundle for these things, so
> you could always make your own. However, since it uses the
> FileConfiguration name for the bundle, which is the same as the class, I
> don't think it's currently possible to make a bundle-as-class. I could
> change this though.
>
> Would that be acceptable?
Sure, would be perfect.
/Paul
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
