World: r3wp

Like so:

1. create dir test/ in the doc root folder.
2. create empty file index.html in test/
3. try to display in browser: no go
4. insert char "a" in index.html
5. "a" is displayed in browser.
6. remove "a" again so index.html is empty
7."a" is still displayed in browser.


If I navigate away and then back to that page using the Back button, 
it still faithfully displays the "a".


If I directly enter the url for the index.html file, I get bounced 
back to the previous URL.

webapp won't work, even with an app-init.r file, but it works fine 
with an HTML page.

I guess what I really want is the feature of virtual-root for a webapp, 
but just for plain RSP pages.

Another potential issue is when a virtual-root has the same name 
as a real directory at the default root dir. I don't know if that 
can be warned for, but it caused some confusion here before I figured 
out what was wrong.

I'm bubbling with question regarding webapps. :-) Because I can't 
get them to work according to what is written in the docs.

webapps work fine for me.

maybe your browser is caching.

attempt [load join request/config/root-dir %/app-init.r] ; TBD: report 
errors !!!

Maybe it's this line in the code that is giving me issues.

because app-init.r is quietly not run

my curecode works fine, but my own app does not work

cure code is a web app is it not?

RSP: error in events from %app-init.r now logged.

That's from the change log. That's not correct.

for cheyenne 0.9.19.

yes, it's a webapp.

I'm not entirely clear at all from your description what the issue 
is.  But I presume doc is working on fixing the email issue and if 
there are others ... he'll get on to them.

In the meantime I am holding off deploying the latest SVN version 
of Cheyenne.

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 !