World: r3wp

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]...

Use the provided TestApp webapp sample to get a real working example. 
You can build your app by copying testapp code, then customizing 
it if you don't feel yet comfortable with webapps framework.

Graham: I'll release a new SVN version in a few hours after fixing 
known bugs/issues and rewritten netutils and file attachement stuff 
to get rid of Rebol non-conforming legacy code.

No rush ...

I need it to be fully operationnal for tomorrow, we're starting UAT 
for a customer app relying on it. ;-)

Correcting myself about my claim regarding CRLF not sent by REBOL 
built-in protocols : REBOL does send CRLF even if 'newline if used 
as line terminator. A conversion is applied and it becomes CRLF once 
inserted in the port. This automatic conversion (LF=>CRLF) is OS 
independent and is triggered by /lines refinement used on OPEN native 
in root-protocol/open-proto. AFAICT, this behaviour is not documented 
explicitely anywhere. I can just find a few mentions about such conversion 
here : http://www.rebol.com/docs/core23/rebolcore-12.html, but it 
looks like it's related to FTP scheme only (while in fact being the 
default for all schemes relying on OPEN-PROTO).

yess.  I've had to battle this in the past when its not desired.

I wonder if the /lines is a recent refinement or if I just never 
noticed it.

IIRC, it's here, at least, since v2.0.

here=>there

darn, a single little thing goes unnoticed and this ends up causing 
so much grief!!  :-)

bad side of working with black boxes...

<sigh!>  I wish I'd known about /lines hehe... I had to go through 
countless hours trying to fix the headers and when doing multipart... 
god... it was horrible to fix.  ;-)

I ended working in binary mode exclusive, this way I could at least 
get precise lenghts... which didn't change halfway through the process 
 ;-)

exclusively.

most rfcs of that time user crlf

Well, as soon as it is updated ... I'll be ready to test the MTA.

SVN r21 :


FEAT: log verbosity handling refactored, now more consistent across 
modules

FIX: email.r lib doesn't interfere anymore with other Rebol built-in 
schemes
FIX: bug in multipart/form-data decoding in RSP.r
FIX: email.rsp demo script now handles attached file correctly

wow that was quick!

and the windows 7 issue?

Couldn't access my Win7 box, so could test it. I'll be able to do 
that only tomorrow.

If you're still having issues with the MTA, please active maximum 
log level : -vvvvv and send me the output on private channel or by 
email.