17 Feb
2015
17 Feb
'15
2:14 p.m.
On Tue, Feb 17, 2015 at 2:04 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
Just to be clear: I’m -1 till I understand why we need
a new concept and why deciding where we put our temporary directory is not good enough.
To summarize my position:
* Cache files are temporary files. They can be recreated. And it’s not because files are
in a temporary folder that they have to be deleted every few minutes :)
* In order to prevent some process to mess with our
temp files when XWiki is running (for ex) we could want to control where we put our
temporary directory. This is already configurable and doable
Temporary directory is not configurable at XWiki level so it depends
on the application server.
Now when in a Servlet environment we already put temporary data in the Servlet’s
temporary directory (which is **NOT** the OS temporary folder). That container temporary
folder is not deleted or removed by any process. It is already a safe place where to put
our data. That’s why it exists! ;)
So I wouldn’t change anything in the end ;)
What have I missed?
Thanks
-Vincent
On 17 Feb 2015 at 13:44:24, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
> Hi,
>
> On 16 Feb 2015 at 17:13:45, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
>
> > Thanks for your answers.
> >
> > I change the name of this thread since my proposal has changed:
> >
> > 1 - Add getCacheDirectory() in the class Environment:
> >
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki…
>
> So if I understand correctly:
> * Permanent directory: mandatory data that is needed for XWiki to work and that you
need to keep when you upgrade your XWiki instance
> * Cache directory: data used to make XWiki faster but the data in there is not
mandatory (it can be deleted) and is recreated if not found
>
> Now what about the temp dir:
> * Temporary directory: not used?
>
> Basically it seems we want a controlled temporary directory, correct? What would we
put in the temporary directory? Data that can be removed between XWiki startups? The
difference seems pretty slim and your proposal doesn’t explain that.
>
> At this point I’m not sure I understand enough the differences between the Cache dir
and the Temp dir to vote.
Yes something you can recreate but that make sense to keep between
restarts (which is far from being the case of all temporary stuff).
IMO we would also move embedded solr index in this new directory for
example.
>
> > It means breaking an interface.
> >
> > 2 - Add a cache directory setting in xwiki.properties, to change this
> > directory if needed (for example: set a directory on a faster disk)
> >
> > 3 - For our distributions, set this cache directory in a folder inside our
> > distributions (for example a "cache" directory aside the
"data" directory).
> > This setting can be changed by the user.
>
> This will work only for the Standalone zip distribution and the Debian one. What
would be the default location for the Debian distribution?
As I suggested in the other mail thread the default path for Debian
package would most probably be /var/cache/xwiki/. What is important is
that it's configurable at build time like permanent dir is.
>
> What would be the default value for the WAR distribution?
>
> I think I’d put the temporary directory as default and issue a warning, as we do for
the Permanent directory, WDYT? Technically this means using the temporary directory in the
Environment’s implementationq (StandardEnvironment, ServletEnvironment) by default if not
set.
>
> > 4 - Do not purge the LESS cache on startup.
> > (see my previous mail for this)
>
> It’s not only LESS. This whole cache directory should not be purged on startup.
Guillaume is talking about LESS infinispan filesystem cache configuration here.
5 - add a new module that pre-generate the LESS
cache file to make the
first XWiki launch faster
(see my previous mail for this)
+1 for all of this.
+0 on the principle but I haven’t checked the complexity that it brings. I guess I need
to read that other thread first (will reply there if I have any comment).
[snip]
Thanks
-Vincent