World: r3wp

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.

I am thinking of building a session server for remark. an uber simple 
multi-tcp port server which implements liquid-net and synchronises 
the remark handlers, in a lazy way.  so unless the users are actually 
calling for pages.... no network traffic occurs between processes.

not as good as mem copies, but should still be effective and scalable.