World: r3wp

Sorry, if I'm rambling a little bit. It's what I'm observing that 
is straight reposted here. Moving a few milimeters forward after 
a whole day's work is a bit frustrating, particularly when it's REBOL. 
:-)


Right now I just see that app-init.r is not run and that the loading 
of it is wrapped in an ATTEMPT in Cheyenne's source, so I basically 
can't see what's going on. From the docs it appears that the app-init.r 
file is required for a web-app, but request/web-app returns a web-app 
name. So am I running a real web-app or what's going on?

remove the attempt

and log the error instead

cheyenne straight out of svn comes with a web app .. does that work?

I use the encapped version here.

of cheyenne?

can't re-encap or switch to using source version?

after a lot of experimentation, the latest encapped version was the 
only one that worked properly.

So, which encapped version is faulty and which one works?

Doc needs to remove faulty binaries if they are still available for 
download.

is there any real advantage to using the binary version of cheyenne 
wrt the source version?

Yeah .. users can corrupt the source files

how is that possible?

if you have uniserve and cheyenne.r ... of course they can fiddle

by users you mean the people running the server or web users?

oh ... I distribute cheyenne to end users as an embedded web server

ah ok, yeah in that case you want to give them the bin.

but I really meant, feature-wise...

don't think so

btw, the svn setup is cool  :-)  good work doc

I wasn't particularly favoring the binary version, only that after 
a day's experimentation, that was the only one that worked properly 
for me. When in such a situation, it's better to stick to one with 
known bug record, so I can tell whether it's the binary or me that's 
doing something wrong.

so, the main advantage is the practicality  (it also easier to update 
a single binary than a whole repository on the server itself :-)

source version on development sites only

so, now app-init.r works for whatever reason. at least I can observe 
that changes to app-init.r only take into effect after restarting 
Cheyenne.

Two other issues in the 0.9.19 source:


1. INCLUDE and INCLUDE-FILE do not process paths identically. This 
is not mentioned in the docs.

2. INCLUDE won't include files in absolute paths. It simply changes 
the path to the current path which stores the RSP file that is currently 
being executed. I can't say that I have a fixed include directory 
somewhere at an absolute path. I don't see the purpose of altering 
the path like this.

Sometimes Cheyenne also outputs a lot of junk prior to the real content. 
This seems to coincide with a failed INCLUDE. Rebooting Cheyenne 
stops the problem.

You tried "reload configuration" ?

how do I do that?

rigth click on the chyenne icon in the system tray

It may not reload the app-init.r though

I use include and include-file only to include files inside the web 
app ... never tried it otherwise

used for footers, headers, and Javascript libraries

Quick warn on current email lib in Cheyenne: it was reported that 
my patchs to REBOL internal functions for RFC compliance are breaking 
some builtin protocols (HTTP e.g.). That's caused by other LF (instead 
of CRLF) deep buried in most protocols implementations conflicting 
with my patches. I'll remove my patches in next SVN build and recode 
all the stuff.

so no email !

I don't really understand your issue about RFC .. I send email to 
gmail all the time .. it never gets rejected

spoke too soon ... two of them just ended up in the spam folder1

Graham, I'm running Cheyenne on a remote headless Linux server, so 
no system tray. :-)

Oh  you need to change to windows ASAP

:-)

not happening. besides, I prefer knowing what Cheyenne actually does 
than beating on a black box with a club to make the black box work. 
:-)

My app reports errors back to me ... 

I do a set-net [ [myemail-:-gmail-:-com] gmail-smtp-in.l.google.com ]

and then send the message to me.

I don't need to use SSL/TLS because the recpient is also a gmail 
account.

DocKimble, I've rambled a lot the past couple of days. I still have 
more to come. Can you make sense of it or should I compile a document 
with suggestions?

Why don't you use it more and then report back ?

I can waste the next two weeks figuring out how things don't work 
in Cheyenne.

or I could wait for some comments and more documentation by DocKimbel.

Henrik, trying to answer your questions/issues :


to serve multiple document roots on the same site without having 
separate domain names

 => Use sub-domains for such isolation. Everything that's under one 
 domain can be accessed with /.. parent syntax. I think that you can 
 hack it around with ALIAS, custom webapps on-page-start event  handler, 
 but there aren't clean solutions. Use sub-domains for such isolation.

I think webapps require a bit more than static pages?

 => Just to make it clear, webapps are REBOL applications interfaced 
 with external world using RSP scripts. Webapp are not meant to be 
 container for *only* static pages (HTML/CSS/JS/images).


attempt [load join request/config/root-dir %/app-init.r] ; TBD: report 
errors !!! [...] 
RSP: error in events from %app-init.r now logged. 
That's from the change log. That's not correct.

 => Yes it is. What's being logged so far is the errors caught at 
 runtime in event functions declared in app-init. What need to be 
 logged is the LOAD %app-init.r process (syntax errors at boot time).


after a lot of experimentation, the latest encapped version was the 
only one that worked properly.

 Both encap and sources versions works well on Win/Mac/Unix. The issues 
 you have are related to running a rebol app as daemon in console 
 mode on a remote Unix server (without a UI desktop). Cheyenne can 
 work in source mode on such server, but it's much easier and pratical 
 to use it in binary form in such case (typical remote linux server 
 case).

so, now app-init.r works for whatever reason. at least I can observe 
that changes to app-init.r only take into effect after restarting 
Cheyenne.

 => Webapp are persistent application in memory. RSP pages will be 
 reloaded on modification but %app-init.r can't without "restarting" 
 the whole application. As there's no clean/reliable way to completly 
 "unload" a Rebol app from a Rebol session, it requires to restart 
 the whole processes (all the worker background processes that may 
 have run your webapp). This can be achieved either by restarting 
 the whole server, or better, by using the "Restart Workers" feature 
 (documented in the changelog file). For unix: kill -USR1 <pid> (where 
 <pid> is Cheyenne main process id).

Btw, the usual way to not have to "restart workers" on each app-init 
or other memory cached code is to run cheyenne with -w 0 option (use 
only 1 worker process and kill it after each request) and some verbose 
output for debugging :

 ./cheyenne -vv -w 0 &

on each app-init or other memory cached code [modification]...