World: r3wp

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

Doc, it works, with -vvvvvv and even when I've run it as root first. 
It can't create all its logs then, but at least it doesn't crash. 
Thanks again!

Doc, trying to start cheyenne   on win7 with UAC enabled, I get this 
error message: 

You need administrator rights to switch to Windows Services mode 
!
   

thing is I've never tried to switch to windows Service mode!!!


a part from the warning popping up the rebol console, the app seems 
to work ok.

this is with all releases I've tried, including the v142 release.

the warning popping up the rebol console
 Are you running it from sources?

yes

Looking at the sources, I've found a code path leading to this error 
msg where the internal /quiet refinement is not honored. Fixing that.

stupid question, can the source version run as a service, or only 
the binary one?

IIRC, you can run it from sources too. Instead of putting cheyenne.exe 
as the service target, it will put rebol.exe.