Re: A patch to keep cache directory out of webroot

"jojodee" <[email protected]> wrote in message
news:[email protected]...
> "Jonn Beames" <[email protected]> wrote in message
> news:[email protected]...
> >
> > (mostly just replacements of hardcoded var paths with calls to
> > xarCoreGetVarDirPath())
> >
> > This works, but I'm sure there are other ways to acheive the same goal.
> > What do people say?  All are welcome to participate in the process.
>
> Don't want things to get mixed up - ie we are talking about a cache
> directory, and we are also talking about somewhere to store our
> config.system.php file  for xaraya install and xaraya boot ...
>
> Two aspects I'm interested in in more detail and feel it needs to be
thought
> out more generally in relation to many areas:
>
> 1. Could I ask what is planned to be stored in the /var path ? Or another
> way - what will the /var path be used for, or what do we want and not want
> it to be used for given it is used for many things at the moment? I'd like
> to see a clear and specific definition or listing of what will and won't
be
> stored in the /var path.

If ownership of var data is handed out to modules, then we only need to
consider the directory structure for handling that. Modules can chose what
they do themselves within their own var space. Once we know where modules
are going to be playing, then the future is open for monitoring these areas
(e.g. giving different modules different disk quotas, either
programmatically, or through the operating system, or some permissions
scheme could operate in a module's var space etc.). An admin could also send
different modules to different var spaces if desired (the messaging var
space may be shared across multi-sites, for example). That may or may not
happen, but at least it could be implemented if modules were allocated and
managed their own var space through APIs.

> 2. Access or configuraiton options for:
> a.  those that do and do not have access to directories outside of the
> webroot.
> b. those that are on different operating systesm (Windows vs *nix)
> c. dependent on 1. above - ie what is the /var path used for?
>     (multisite boot?, cache? etc)
>
>  I'll prefer to see something like:
>
> /var directory - only minimal configs or vars to get Xaraya bootable or
> installed.
>    This remains  where it is.
>
> /site directory (configurable) on a per site basis
>     (including one and only site if that is all there is - for
consistency).
>      - /configs or vars whatever you want to call it

>      -/data - where site wide message templates, images :), workflow etc
> data goes

I would argue these all belong to modules, whether the mail module,
images/uploads, workflow etc.

>      - /themes (this is configurable now and can be setup to point to an
> existing theme dir or any other dir)
>
> If any modules require extra or different web or not web accessible space,
> then they should handle that themselves as a configurable option, but
using
> the above, for example, as a basis. Otherwise, I believe it becomes too
> complicated for initial setups.

An API for managing the data areas should allow each module to set up their
own space in the var directories. They should be able to specify in their
setup script "give me some var space please" - and it will be created for
them with appropriate permissions. It does not need to complicate the
initial setup though. Perhaps if there is default data (i.e. defaulf files)
that should be placed into a module's var area, then those defaults should
be kept in the module itself, and copied in during module installation. It
would mean an installation could be shipped with a vitually empty var
directory, and therefore nothing to be overwritten when an upgrade is
performed.

> xarCoreGetVarDirPath () should default to /var where it is, but also maybe
a
> param:
> xarCoreGetVarDirPath('site')...

Would each site not run in the context of a single site - i.e. would there
really be a need to access the data in other sites? The idea of separate var
directories for separate sites, is to keep them separate.

...


-- JJ