World: r3wp

The only files that can't move (on UNIX) are: httpd.cfg and "error 
log" files.

And there is my current problem, because these have very different 
access privileges

It's not hard to solve. We just need configurable locations for these 
parts

Can you list me the "standard security practices" that you have in 
mind that can't be implemented using current behaviour?

The list I gave above of the main functional areas of any significant 
application

These need to be located and given access privileges according to 
the conventions of the system

As I understand it, this looks like Cheyenne will need a per-UNIX 
system install script? Or will we let users spread the files acrosse 
the filesystem as they want and use options to redirect properly 
each file classes to the right folders?

Not at all. As I said, we just need configurable locations

The only things really missing are paths to the configuration file 
and the main logs area

The way to set them in non-default situations is the responsibility 
of the system integrator

A clear way to set the path to the UniServe library in the source 
version would also be good. I patched the Cheyenne source for that 
so far

Let me clarify that. The path not just to UniServe, but to all support 
libraries, modules and such

You mean when running %cheyenne.r from a remote location?

Remote from its support files, yes, but just on one machine

Here's the structure in Syllable:

Packages:

/resources/

/resources/Cheyenne/

/resources/UniServe/

Structure of a package:

programs/cheyenne for the binary version

framework/libraries/ for support programs

data/ for other support files

Structure in the system:

etc/httpd.cfg Ugly legacy Unix name, and currently impossible. Would 
like Cheyenne to use any location and name

/var/log/ Ugly legacy Unix name, but standard place for logs. Currently 
only possible by starting Cheyenne source version from /var/. Impossible 
with binary version

/users/Kaj/tryrebol.esperconsultancy.nl/ Sites can be anywhere

Software conforming to general open source and GNU conventions has, 
often standardised, options to appoint all these locations, at build 
time or at run time

Thanks for the detailed review. I think I will need to work on an 
abstraction layer for files location in all possible cases: sources/binary 
x platforms.

I'd hope it would be quite simple, but I don't how the encapper works

don't know

It is absolutely not simple:
- Cheyenne binaries use a memory-based virtual file system.

- When run from sources, files internal relative paths depends on 
where the REBOL binary is run from.

- REBOL on Windows has 2 different working folders (one for REBOL, 
one for the system), while on UNIX, it seems that there is only one 
(from the REBOL POV).


Make a cross product of items and you'll have all possible combinations 
to manage.

Bummer

I would like to take this opportunity to clean up things and hide 
the low-level mess under a unique abstraction layer.

I think I will make a new virtual filesystem for Cheyenne that will 
abstract all files accesses (including web sites). This would have 
the additional benefit of allowing to encap web sites files too (a 
feature I wanted to have since a long time).

This is quite a big change, so will need several steps to complete. 
I will first just patch the current way to allow relocating config 
and error files for UNIX users.

can we start out with a documentation / sample implementation 1st, 
please?

it sounds like a project which can be very well reused in other cases 
too.


i've outlined the mentioned directory areas here: http://piratepad.net/KkvkZ9AtME

Thanks for the summary. I need to study every cases first anyway 
and find a clean and simple way to implement it. My first idea would 
be to use a custom scheme for that, like vfs:// that would resolve 
all virtual paths transparently.

Does the encapper modify the file scheme? Couldn't that be extended?

No, the encapper has no effect on file scheme.

File scheme is native, so no, it can't be extended.

Is the VFS in the binary your own, then?

Yes, but it is a very basic one and you need to use custom function 
calls, like: do-cache, load-cache, read-cache....

Ah, that explains the differences between the binary and source versions. 
It would be good to neutralise those

It would also have been good if the file scheme in REBOL were hackable. 
Per-app namespaces are always useful

You'd basically get the framework Tamas wants

Any problem in computer science can be solved by adding another indirection.

Kaj: I have pushed a fix for the verbose mode making Cheyenne crash 
when running as none-root. It works well here on my Linux box. Let 
me know if you have other issues (locally generated files issue aside).

btw, http://equi4.com/starkit/index.htmlis an encapping solution 
for tcl.

i just accidentally saw it mentioned in a rebol blog entry: http://www.rebol.com/cgi-bin/blog.r?view=0375#comments
 :)

TCL has a capable VFS, similar to REBOL