World: r3wp

No, but it's in my todo-list for the next release (0.9.20).

cool, I will be very happy when this is possible :)

Is there a way to associate a particular listen port with a webapp?

like 

webapp [
	listen [ 8000 ]
]

Nope, but you can bind a domain to a specific listen port. For ex:
globals [
	listen [80 8000]
	...
]
my.domain.com:8000 [
	webapp [
		... 	; this webapp should only be accessed through port 8000
	]
]

But you should test the webapp domain:port isolation, I remember 
having bugs there and it seems to me that there were fixed, but I'm 
not completly sure.

I'm seeing some odd root kit like behaviours ... cheyenne is clearly 
serving up pages,, but the icon is gone from the system tray and 
it does not appear in the processes list in the windows task manager!

This looks like it's working in service mode. In Task Manager, be 
sure to list processes from all users (including services).

If it's not the right explanation, then that means that your Cheyenne 
instance evolved, became self-aware and decided to hide in order 
to survive, so we shouldn't have to worry much about anything now. 
;-)

It's a concern...

Nope, it's not in services

I'll check it again if it happens again .. but it could just be a 
single evolutionary event

Of course reload config and run as a service are pretty close to 
each other ...

ah... silly.  I was running Cheyenne as a service using Firedaemon 
and had forgotten already :(

I've got some virtual sites set up as this

jerrys.com [
	root-dir %/z/pwp/www/	
	default [%login.rsp %index.html %index.rsp %index.php]
	webapp [
		; jerry's
		virtual-root "/md"
		root-dir %/z/pwp/www/md/
		auth "/md/login.rsp"
 		databases [ emr odbc://jerry ]
		;debug
	]
]	
grahams.com [
	; 3 changes, and the app-init.r
	root-dir %/x/pwp/www/	
	default [%login.rsp %index.html %index.rsp %index.php]
	webapp [
		; grahams
		virtual-root "/md"
		root-dir %/x/pwp/www/md/
		auth "/md/login.rsp"
 		databases [ emr odbc://graham ]
		;debug
	]
]

However, once someone enters one webapp, and authenticates using 
the database emr, then in the other webapp, emr now refers to the 
emr that was first opened :(

I did a search and replace to change the database handle in all my 
source rsp and r files, and altered the definition in the webapp. 
 that also does not work

But what does work is placing the database in globals.

so I have this

globals [
	databases [ db1 obdc://graham db2 dobc://jerry etc ]
]

odbc ...

in each of the above webapps, I have an app-init.r where I have defined 
myhost: blahblah ... so this is a global to be used by this webapp.

Unfortunately it looks like as soon as one web app is started by 
a visitor, then all webapps take the same value.  The value is not 
kept in the webapp's context

I have some time allocated today to work on Cheyenne so I will give 
it a look.

Thanks

Graham, I can't reproduce your issue. I've tried with the following 
config options : 
site1 [
	webapp [
		virtual-root "/curecode/"
		root-dir %//dev/curecode/
		locales-dir %private/locales/
		databases [
			bugs	mysql://[root-:-localhost]/bugs
		]
	]
]
site2 [
	webapp [
		virtual-root "/curecode/"
		root-dir %//dev/curecode/
		locales-dir %private/locales/
		
		databases [
			bugs	mysql://[root-:-localhost]/bugs2
		]
	]
]

Site1 shows me tickets from "bugs" db, Site2 shows me tickets from 
"bugs2" db. (Both site1 and site2 are mapped to localhost). Test 
was done using a IE session on site1 and a Chrome session on site2.

Were they done concurrently?

Both your virtual sites refer to the same physical location on the 
drive .. which is different to my setup.  I presume it's not important.

I'll see if I can replicate the issue on my localhost as well.

However, I was only able to get my production server working by using 
different database handles.

What i sthe best way to have cheyenne send me an email alert when 
a user does something on my site (for example:  Leaves a comment 
on the comment page)


I tried to "launch" a small script but a new instance of cheyenne 
seems to start and continue running...I would think not desirable...

I was lauching from within an .rsp page..

It's just rebol ... so just use send

The page is a loop so after the comment is submitted the page refreshes 
with the new comment displayed...I was afraid if the "send" got hung 
up it would be annoying for the user to wait....

Even when things go normally send there is a bit of a delay....

its all about the experience!

I added "quit" to the end of the script but NO change to the behavior.

I should hope not.  'Quit would cause the cheyenne instance to shut 
down unless it had been redefined which I presume it has.

So, your comments page has a form on it where the form action is 
itself?

I can't see why there would be much of a delay ... do you have a 
mail server running on localhost?

If you don't want to use email, you can use twitter instead ...

I just tested it and its seems fast enough....I guess I'm used to 
poor, slow connections with long hangs...	
Thanks for the suggestion Graham.


Its actually better this way as I can now include more info with 
the email such as who is sending it and what the message is...

Graham: I need to test it again, my Cheyenne instance was configured 
in debug mode (-w 0), so worker processes were reset after each request.

Ok, now using production mode, I can reproduce the issue. I'll fix 
that asap.

Issue fixed in SVN r5. It was just a typo caused by copy-pasted code.

amacleod: I'm planning to work in the next weeks on integrating an 
async Mail Transfer Agent in Cheyenne, so sending emails will not 
blocks CGI or RSP scripts.

doc, does that include the app-init.r issue?

Sounds very cool,Doc. Thnks for the info...

App-init.r : if you define a word! in a RSP script or in app-init 
event handlers, remember that it will only exists in the worker process 
context where it was called. It won't be defined in the other worker 
processes, so it will likely produce errors in your app. The only 
safe and multiprocess way is to use session object. This means that 
you currently can't have such thing as webapp global words (but you 
can at the session level).


If REBOL had multithreading or, at least, an efficient IPC between 
REBOL processes (like shared memory), you would have such feature 
since the beginning. I was reluctant to extend my custom IPC to allow 
shared global values for RSP script because it would have an impact 
on performances, but maybe the added value worths it and the impact 
might not be so big (basically, a MOLD/LOAD + 2 TCP transfers of 
all shared data for each request). Perhaps, it's time to reconsider 
adding this feature?

Humm, on second though, it might be much more complicated, because 
it would require a synchronization mechanism for value modifications 
between all worker processes (which is very inefficient using TCP 
ports).

I've not had any issues before I used virtual web hosts .. and then 
my "global" app-init.r word spilled into the other web hosts

and other webapps