World: r3wp

http://cheyenne-server.org/wiki/En/Sandbox
i distilled what we just talked about recently.

dunno which page should be the best for hosting such info, so im 
just braindumping here for later organization

btw, let me micro-interview you here: why the hell are u still using 
windows!? especially for development? :)


I consider that GUI are an improvement over CLI that make my life 
easier and computers simpler and more fun to use. I stick with Windows 
as my main platform because I never got used to Mac OS UI (tried 
for a few weeks, but gave up rapidly) and I found the other UNIX 
GUI less "efficient" than Windows. Also I found Windows to be quite 
transparent for my work, it just doesn't get in my way as other OSes 
tend to do, so I can focus on my work and forgot about the rest (especially 
since Vista days, I am now a very happy Seven user).


I must also add that I was an Amiga and BeOS user for more than a 
decade and spent all my college days on AIX, X-Windows and SunOS.

X-Windows => X-Window ;-)

:) thanks. interesting.

i was doing DOS, TurboVision, then tried Win3.0. used Turbo Pascal 
in 2 dos windows under Win3.1, programmed serial equipement with 
Delphi 1.0 under Win95, but then i just fell in love w the fvwm2 
theme of icewm and the big virtual desktop which even worked on trident 
8900 isa cards, using suse linux. i was forced using windows until 
the xp version and i even saw delphi 4.0.

no windows interface can compete with icewm with autofocus and saying 
this as someone who still can handle windows without a mouse faster 
than anyone else i know.

i found vista and win7 particularly disgusting. those dim windows 
w huge decorations just make me annoyed.
im the fullscreen terminal window in black&green kinda guy :)

i want console in web browsers too. i think lisp machines were great 
examples that how the character based interface can benefit from 
graphical capabilities.

plan9's acme is also a nice example; although i never had the chance 
to use it for anything real. never really seen an expert using it 
either...

btw, this is how im listening to netradio rightnow:
$ mplayer http://lounge-radio.com/listen128.m3u

and the good thing is, i could do the very same under windows, while 
i had my windows netbook

hmm.. cookies are accumlating again... Cookie: RSPSID=GWKAQXFYMANHFHNXLXXKVVWL; 
RSPSID=VDWMLITKUVGDAFQBHJHHCQDH

but the app still works. am i confusing it somehow, by restarting 
cheyenne... but im closing the tab and reopening it too...

this /favicon.ico pollutes the output... how could i get rid of it?

No, it a browser thing (unless you can disable it in your web browser).

IIRC, older session cookies stay if the session has not been explicitly 
ended (using response/end), or until browser window is closed

Cheyenne uses volatile cookies (with HttpOnly attribut) that are 
safe for holding a session key.

hmhm... the auth directive is not completely useful for me, because 
probably i shouldn't return a 302 to the login page when the session 
of my json service times out... :/

I'm stuck in my attempts to get Cheyenne to run as non-root. Some 
observations along the way

The encapped version of Cheyenne needs to be started from the directory 
of the configuration file in order to find it. Then it produces its 
log files also in that directory. This is both against the structure 
of Unix and modern Windows systems

To produce the logs, Cheyenne needs write access to the folder with 
the configuration file and (future) logs. This becomes a problem 
when it gives up its root capabilities, and the mechanism to adapt 
the privileges of the log files still doesn't seem to work

When Cheyenne has access to this directory, but only for reading, 
it quits silently. -vvvv doesn't even provide a clue what went wrong

When it gets write access, it produces a crash.log under the new 
user name, showing that it switched. But it had already produced 
a normal log under the root name, and doesn't adapt its ownership. 
This is indeed what the crash.log then warns about

Ah, the problem is the -vvvv itself. When I start Cheyenne with extra 
logging, it creates the log earlier, so that it ends up being owned 
by root

Running as non-root is very tricky. I've stabilized it until the 
introduction of 'access-os. I will make more tests today.

This is both against the structure of Unix and modern Windows systems.


UNIX filesystem layout usage are not identical. Here are the Apache 
error log location in just 3 UNIX flavours (among dozens):

* RHEL / Red Hat / CentOS / Fedora Linux Apache error file location 
- /var/log/httpd/error_log

* Debian / Ubuntu Linux Apache error log file location - /var/log/apache2/error.log

* FreeBSD Apache error log file location - /var/log/httpd-error.log

and here are the possible locations of configuration file:
* /usr/local/etc/apache22/httpd.conf
* /etc/apache2/apache2.conf
* /etc/httpd/conf/httpd.conf


Notice how the file name changes too (both for the log and conf files). 
BTW, I personnally prefer the GoboLinux approach ;-).


One the Windows front, it is barely better. The registry database 
is fine for storing parameters (name/value couples), but not a REBOL 
dialect file. A common way is to store files created at runtime in 
%USER%/AppData/Local/<appname>/. Cheyenne stores all his files (including 
config file) either in the local folder or in %ALL_USERS%/Cheyenne/. 
Storing them in %USER% hierarchy should be better.


Taking into account every OS specificities (or oddities) is not always 
a good choice for a cross-platform product. I know that Cheyenne 
needs to be gentle with the OS best practices, so I am willing to 
improve it whenever it is possible, but without sacrificing the default 
behaviour (because that is the way I want it to work for me).


BTW, I am also willing to test the centralized logging approach, 
but it has to be a cross-platform solution. So an abstraction layer 
needs to be built with connectors for UNIX syslog daemon and Windows 
Event Logger (they are two types to support: pre-Vista system and 
new Vista/7 one). Has anyone already worked on such wrappers with 
REBOL?


I personnaly need that the log files be exactly in the same format 
and if possible at the same place across platforms to make my life 
easier, so this will keep being the default anyway. The current -f 
internal Cheyenne command line (Windows specific currently) could 
be extended to work on UNIX too (and no Max, this one cannot go into 
the config file, because it indicates where the config file is located 
;-)).

I don't mean the specific implementation of the structure of different 
system, but the general principle. Most areas of the general structure 
are applicable to Cheyenne:

- Program and accompanying files such as libraries in the source 
version (may have different subareas)

- Configuration data. The httpd.cfg file

- User data. The websites. May be segmented over multiple user accounts 
or a global area

- Log files

Cheyenne currently just does and dumps everything in the directory 
that happens to be current. Only for site data are options to put 
them elsewhere

Access logs can be redirected to any folder.

PID file can be redirected as well.

This is awkward because these areas have distinctly different characteristics. 
These walls will be run into as soon as you try to implement standard 
security practices

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