World: r3wp

Because you need to "refresh" the .encap.fs cache file before encapping 
by running Cheyenne in source mode at least once. This procedure 
has to be done each time the SET-CACHE spec block in %cheyenne.r 
is changed.

I use Cheyenne as a helper application.  Now my main application 
occasionally has to access files from S3 but synchronously.  Since 
the s3 tools don't have async versions, does it make sense to perhaps 
to use RSP to download the S3 files I need.  I can call RSP async 
from my app.

Could you just use UniServe with async HTTP protocol? (I can put 
it online, it's not part of Cheyenne package)

Seems that I have a problem with session handling in that I don't 
get a new session when I expect it.

I use session/id as a filename to store some temporary data between 
requests. But it seems either that session/id is not that renadom 
or that a session somehow survives a long time.

How is a session managed? When is it created and when is it destoryed?

It seems that I somehow get back an old session/id from someone else 
even I just opened my browser and loaded a page.


This problem shows in my REST shopping cart in that I get a shopping 
cart from someone else.

The code handling this looks like:

; GET
startsession
 [
  unless session/active? [ session/start]

  if load-cart session/id [show-cart]
]

; POST
addtocart
 [
  ; do we have a browser session?
  either session/active? [
     load-cart session/id
     ....

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.