thanks, for getting back
I was referring to a setup where backends would not have shared disk 
storage but only shared session storage. in this case every backend 
webserver will generates its own uniquely named resources. thus 
requests for js/css will fail since they are unlikely to hit the same 
backend.

For those kind of setup it would be nice if file hashes would contain 
version or content and not modification time.

Just saw this last comment...
They are not "randomly" named.  The name is the cache key - it is a 
hashed combination of the filenames contained in the file + the 
modification dates of those filenames.

Pages that use the same list of js/css files can re-use the existing 
files.  Modifying one of the constituent files will cause a new 
filename to be used/created.

Why?  The files should be named the same.  i.e. the first connection 
to imp on a cluster results in a js file being created for the mailbox 
page -- all users will then use this file.

hey, thanks for the fast reply. making the path configurable is quite 
nice in it self, but i meant something slightly different.

my initial problem was the following:

i have several horde installations behind a load-balancer. this one 
uses session-binding to redirect a certain user to a certain backend.

now i tried to serve the static assets through a different pipeline 
than the rest. so i configured a reverse-proxy to deliver them. since 
its only static assets i figured i don't need the session binding and 
it can fetch the assets from an arbitrary backend.

but since the assets (e.g. compressed js files) seem to be randomly 
named, when the request for assets goes to an arbitrary backend, they 
will not match the filenames produced by the replying horde instance.

of course i could just collect all assets and serve them from a 
separate place (that's probably what i'll do), or as you suggest in 
the conf.xml place the assets directory on a nfs share. but still i 
figured it would be nice if the assets had a deterministic name, then 
this would not be necessary.

additionally it would improve cache efficiency, since random names 
also means that every asset has to be cached once per backend on a 
reverse-proxy.

Horde 5.2.

Changes have been made in Git (master):

commit 8fab45af853a09772ad424af3e82dfb15c7e487f
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Sat Mar 22 23:27:11 2014 -0600

     [mms] The location of dynamically served static files is now 
configurable (Request #13070).

  horde/config/registry.php |    4 ++++
  horde/docs/CHANGES        |    2 ++
  horde/docs/UPGRADING      |    8 ++++++++
  horde/lib/Test.php        |    8 +++++---
  horde/package.xml         |    1 +
  5 files changed, 20 insertions(+), 3 deletions(-)

http://git.horde.org/horde-git/-/commit/8fab45af853a09772ad424af3e82dfb15c7e487f

Changes have been made in Git (master):

commit 227d1c57cbeafa8d0a88c0576319eddddfde6163
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Sat Mar 22 23:24:08 2014 -0600

     [mms] The location of dynamically served static files is now 
configurable (Request #13070).

  .../Core/lib/Horde/Registry/Registryconfig.php     |    9 +++++++++
  framework/Core/lib/Horde/Script/Cache/File.php     |    6 +++---
  framework/Core/lib/Horde/Themes/Css/Cache/File.php |    6 +++---
  framework/Core/package.xml                         |    2 ++
  4 files changed, 17 insertions(+), 6 deletions(-)

http://git.horde.org/horde-git/-/commit/227d1c57cbeafa8d0a88c0576319eddddfde6163

We instead need to define the static directory as a configurable 
option in horde/config/registry.php.

To be able to scale Horde to multiple instances, it would be nice if 
the assets (under /static) are named deterministically.

Thus a given pipeline would not have to implement session binding for 
delivering assets, they could be better cached or offloaded entirely.