World: r3wp

I've used YUI with Cheyenne before ... but am now looking at a different 
Javascript library.

jQuery seems to have a lot of traction, and there is this great set 
of introductory videos on how to use it http://nettuts.com/articles/web-roundups/jquery-for-absolute-beginners-video-series/

Note that videos for days 8 and 9 don't work.

Just unpacked 19 again and ran it .. noticed this


16/2-16:33:37.109-# Warning in [RSP] : Include RSP failed: max inclusion 
level reached - file: %inc.rsp !

just running the demo testapp

Getting this when trying to load my login.rsp page in my webapp


16/2-16:46:24.353-## Error in [task-handler-49652] : Make object! 
[
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'protected-exec
    arg2: 'code
    arg3: [block! function!]

    near: [protected-exec/event request/parsed/file get in session/events]
    where: 'fire-event
] !

all I did was create a new webapp directory and renamed the webapp 
directorie to point to the new directory.

Warning message: that's normal and part of the RSP script I use for 
testing. Currently the internal request forwarding system has a hard 
limit (4) on the number of recursive calls. When the limit is reached, 
a warning message is logged.

Error message: it looks like there something wrong with one of the 
'on-* handler in %app-init.r

When you renamed the webapp, did you update all the config options 
in %httpd.cfg accordingly?

Webapps: What is this and how does it work?

From faq:

A webapp is a directory in the webspace which is protected by an 
authentication cookie. It is specified inside the httpd.cfg, where 
there is a sample "testapp".

Well... what is "webspace"`? Is a webapp useable by all virtual hosted 
domains? And what do I do with it?

And how is the authentification cookie made, sent, ...?

It's something like framework... if you check the httpd.cfg, you 
can see something like:
webapp [
	virtual-root "/testapp"
	root-dir %www/testapp/
	auth "/testapp/login.rsp"
	;debug
]

When you that access the server with starting with the virtual-root, 
it's proccessed by Cheyenne using the %www/testapp/app-init.r file 
where are several handlers which are processed by the process. So 
you don't have to for example think how to update session time etc.

Not sure I understand all this (yet). Let me start with a simple 
thing. :-)


Are there are any RSP examples to look at? I just need to get started 
and see how it works.

Would a simple file containing:

<% now %>

work?

I can see that cheyenne processes this page via the revers-proxy 
setup but nothing is delivered. The browsers hangs and shows the 
progress bar.

Ok, I need to use PRINT to return something. Found it.


Hey Doc, give us some wiki logins to collect all these "documentaition" 
snippets.

A webapp is just a container for a bunch of RSP scripts working together 
and protected from outside (you need to log in to get access). There's 
some events that can be used (defined in %app-init.r). There's also 
support for /public and /private sub-folders.

Btw, if you don't know how to build RSP scripts, you should first 
have a look at ASP or JSP online documentation, so you can get the 
concept and usage. RSP API can be found on http://cheyenne-server.org/docs/rsp-api.html

RSP examples, there's several examples in the %www/ folder.

If anyone wants to contribute to Cheyenne's wiki, just send me a 
private message and you'll get an account.

ok, found the problem.  I had some initialization stuff in the app-init.r 
which referred to the old direcctory.

Is there any way the app-init could be placed inside the httpd.cfg?

As a design principle, I don't want to have code inside the config 
file. Why would you need that?

Anyway, you could use request/config in 'on-* events if needed to 
remove static paths.

So I won;t forget about the app-init.r file :)

I'm now using Cheyenne as reverse proxy with lighttpd. Works great. 
All RSP requests are forwarded to Cheyenne.

I run several domains as virtual domains in lighttpd. And I have 
one document root for Cheyenne. The idea is to be able to add the 
same RSP page (like a shopping cart) to severl domains without having 
to duplicate the RSP code pages.

Is this possible? Does Cheyenne know anything about the domains document 
root?

My directory layout is like this:
cheyenne (containing all RSP pages)
domains
	domain1
	domain2
	domain3
	...

If a request to an RSP page via domain2 comes in, I would like to 
be able to reference directories inside the domain2 directory.

Why there is used 'launch for encaped version and 'call for the rest?

in uni-engine.r is used:
launch*: func [cmd [string!]][
	call join form to-local-file system/options/boot [" -s " cmd]
]
There must be -sq not just -s

'launch stopped working in 2.7.6 I think

You're sure? Don't remember reading that in the 2.7.6 changelog?

without the -q it's impossible to run the server as a background.

Launch is what Cheyenne needs. But it doesn't work in Core (but works 
ok in /Pro which is the minimal base for the encap versions), that's 
why I use the CALL workaround to make sure it will work on all REBOL 
flavours.

I hope that LAUNCH would be fully enabled in REBOL v2.7.7, I don't 
see the point in keeping such limitations.

Yes, I reporteed issues with 'launch.   Gabriele said to use 'call 
instead.

I see I reported other issues with launch

http://www.rebol.net/cgi-bin/rambo.r?id=4205&
That one is makred TBD

Just testing with 2.7.6, looks like LAUNCH is only working with Encap. 
"Feature not available..." for all reb* binaries.

How safe it's nowif I would use call from task? For example to do 
image processing?

Is launch/quit working at all??  It wasn't working for 2.7.5

Maybe it was for 2.7.5 and it got fixed for 2.7.6.  I know at one 
stage I had to replace all instances of launch in my encapped code, 
and use 'call instead.

Doing a search .. looks like I was having that conversation with 
Gabriele about the linux SdK and launch in 2006.

Oldes: Graham is using CALL from RSP scripts to do image processing 
IIRC. I never used CALL from RSP myself, so I can't tell. It seems 
to me that it would be faster/safer to wrap an image processing DLL 
than launching a new process for each new request. Using CALL from 
a RSP is like dropping to CGI, you're loosing most of RSP speed benefits.

I have one page of my hylafax application that calls imagemagick 
to convert a tiff to png so it can be viewed in the browser ...

Ok.. then we should write a wraper for imagick, because that's what 
I want to use as well.

Thinking about web-app appliances. Not sure if this idea alreaday 
exists but IMO a good thing to think about.


If I have a RSP based web-app (for example my super-cool-all-you-need-shooping-cart 
system) that I would like to sell it would be nice to bundle cheyenne 
and all the RSP stuff into one package. The user just installs it, 
sets up a simple reverse-proxy and has everything up & running.