World: r3wp

Could try the async http protocol but it's currently written for 
https

When is session created?
 On first request to a webapp resource.

When is session destroyed?

 When you invoke session/end or once the session timeout period has 
 expired and the garbage collector has suppressed it. Not sure what 
 happens if you try to access it after the timeout before GC passing, 
 need to check it.

Ok, trying to access an expired session still in memory, will force 
it to be destroyed and a new one will be created instead (with a 
new ID).

But it seems that you're not using webapps, just plain RSP and manual 
session handling. You should know that invoking session/start container 
will create a new session context but you won't get a new ID at once 
(session/id will be set to none until the RSP page ends). We already 
discussed this point previously and I have an entry in my todo list 
to improve that. (it requires a change in the session ID creation 
process)

Let me know if it's an urgent need for you, I might do a quick change 
in the next revision to give you a workaround.

Graham: did you tried launching a new temporary REBOL process using 
LAUNCH or CALL for sending the requests to S3? (Did I understood 
correctly that your need is to access S3 asynchronously from your 
main application?)

doc, no I didn't as that would start up a new App process which seems 
excessive to just do a download ... especially when Cheyenne is already 
running in the background :)

I think I can just include the S3 libraries in the Cheyenne binary, 
and do a S3 download as a rsp form where I submit the filename, bucketname, 
and access keys

just thought I'd drop a little note that serious remark module work 
has begun.  I was trying some stuff before, but starting too wide 
and I wasn't able to get traction on the project.  now I'm just integrating 
the v2 remark parser into a mod.  


One cool thing that it will do out of the box, is handle statically 
parsed files. basically, you build .html files using remark dynamic 
tags, they are saved out in a cache dir and then the url-file function 
will redirect to the parsed file, if done, or will run the parser 
on it and then cache it.

I need to get my web sites up quickly for a few projects, so this 
is a priority thing... I expect to have the first few quality pages 
functioning within a week.


with a few REBOL projects (some still unheard of) to share with all 
of you guys on one of those sites.  :-)

Session: "On first request to a webapp resource." Hm... I'm not using 
a webapp, just a RSP file. Could this make any problems?

ID creation: My RSP file ends after the "startsession" for this case. 
So, only task here is to either re-use an existing ID or create a 
new one, that is used in all upcoming RSP calls. Hence, I think the 
logic is correct.

Doc, I think that the problem lies somehwere in the session terminating. 
It realy looks like session IDs somehow survive and are re-used even 
for a complete new session.

Could you make a minimal RSP script that shows the problem and send 
it to me?

I'm currently trying to find out how to make it repeatable. It seems 
to only happen somestime (or I don't understand the situation at 
the moment). I add some debug output and will keep an eye on it.

You can use a shorter timeout period (e.g. 30 secs) to test behaviours 
when session timeouts.

doc, I've got some questions about http.cfg vhost redirection...

www.domain.com:81 [
	redirect 301 "/*" "http://www.domain.net"
]
www.domain.net:81 [
	root-dir %/E/dev/project/my-web/web/www.domain.com
	default %index.rmrk

]


should this work?  cause its not .  I'm still getting a request for 
domain.com and a 404 error.  domain.net works perfectly.   

actually, unless I include a root-dir entry in domain.com config, 
I get an error within cheyenne.

Root-dir is mandatory in a domain definition (even if you try to 
redirect everything to another domain).

adding that didn't help in my tests

the thing is, if I redirect, the root-dir of the redirection should 
be used... no?

right, it should.

also note, I tried adding the :81 to the redirected domain and it 
didn't seem to change much.

using the last svn build btw.

looking into mod-alias to see what's going on.

thanks.

I've added your virtual domains definition to my httpd.cfg file, 
added a root-dir to domain.com, added :81 to the redirection URL, 
mapped both domain to localhost, changed domain.net's root-dir to 
%www/testapp and it works ok :

>> read http://www.domain.com:81
connecting to: www.domain.com
connecting to: www.domain.net
== {<html>
<head>
^-<title>Welcome to TestApp web application</title>...

I've also added port 81 to LISTEN directive in config file.

and also changed default file to %index.rsp.

hum... ok, I'll dig deeper ... btw the .net:81 site worked well when 
I was doing my tests, only the redirection didn't fork the call from 
.org:81 to .net:81

simple question, what do the BIND & BIND-EXTERN directives do? I 
may have asked before but I'm totally clueless right now.

BIND associates a mod handler with one or more file extensions. For 
example:


o bind SSI to [.shtml .shtm] : process those extensions through mod-ssi.

o bind php-fcgi to [.php .php3 .php4] : process those extensions 
thru  mod-fastcgi using a php backend.


The ID value used as first argument of BIND is just a hook used by 
the target mod to know which request it should process (as required 
by config file). See mod-ssi.r as an example.

Those associations could have been hardcoded in each module, but 
BIND gives a more convenient way to define and maintain those associations 
than having to change mod-* source code.

ok cool... I'll add a new directive for remark which is bind-static, 
since it treats static and dynamic files differently.

BIND-EXTERN plays the same role for background processed modules. 
All BIND-EXTERN associations will be processed through mod-action. 
The first argument must match an external module file in %Cheyenne/handlers/ 
.

and use bind for the dynamic mode

ok thanks for the extra details... now I know where to look in order 
to integrate mod-remark into cheyenne's current directives  :-)

the first release of mod-remark, next week, will not have a handler, 
but I will be working on that quickly after... in order to make the 
mod more scalable.

If you need to build an handler, there's an old doc that you might 
use : http://softinnov.org/rebol/task-master.html#sect6.

thanks  :-)

I'll probably analyse the RSP handler and mod for proper understanding 
when I get to it.

The choice between adding a mod (main process) or handler (worker 
process) is simple : when a mod function is evaluated, the server 
waits for it to complete before being able to process any other network 
event. :-)

yep... which is why I want to go down the handler road soon.

mod-rsp is quite complex, it does a lot of things. You can start 
by mod-action (which handles CGI), it's like a stripped down version 
of mod-rsp (no session, no webapp, etc...) to get the basics of using 
an handler, then dive into mod-rsp to add higher level features.

handlers seem easy enough to setup, but then it opens up a few problems 
for session concurrency, and stuff, which you already know... so 
I want to iron out the whole dynamic remark architecture before tackling 
the performance issue.

feel free to copy/paste any code from mod-* to your own mod if that 
can help.

Sessions (and especially session data synchronization) is the really 
hard part.

I'll be adding session support and integrated forms creation within 
a few days...

yep... the synchronisation mainly...

It would be so much easier to implement and so much more efficient 
if we had multithreading and a way to share data between threads.

sure... I've impleted some purpose built multi-threaded servers in 
python and its quite easy to do.  probably the last real limitation 
in REBOL right now.