World: r3wp

Well it depends on what you mean precisely with "user login system". 
Sessions associate a context (in the general sense) holding data 
with a remote web browser session. The AUTH config keyword controls 
whether access to webapps resources requires a "login" process or 
not. The login state is reflected in a built-in special word in RSP's 
sessions (session/content/login?). LOGIN? is also settable, so you 
can avoid using AUTH and build your own login system (you'll have 
to overload the 'on-page-start handler to restrict accesses).

Is this something we can use ? http://babelserver.org/rebol/memcached/

You need to setup a memcached server first I guess. Will has implemented 
something similar as a cheyenne mod. I may integrate such feature 
inside Cheyenne in future.

Doc, thanks.

What I need to do is basically the whole package:

Sessions, which Cheyenne can do.
Login process with authentication. AUTH config, perhaps.
Log out process, also possible.
User adding and removal process. This needs to be added.
Privilege usage and management. Also added separately.

I'll have a closer look at the built-in AUTH config keyword.

It's a uniserve service with an rsp interfaces, works pretty well, 
if something takes more than 1 millisecond to execute, better cache 
and reuse 8)
interface is simple:

.cache 'pool-name 'variable-name 'valid-time-in-seconds [code to 
execute]
one refinement, /set , will force update cache

Available to a number of servers?

if you want so, just uncomment or change this line in UniServe/services/cache.r 
:
if client/remote-ip <> 127.0.0.1 [close-client]

I have the latest svn checkout ... I don't see a cache.r  !

Getting this is in the latest Cheyenne when encapped

7-Oct-2009/12:12:03+13:00 : make object! [
    code: 500
    type: 'access
    id: 'cannot-open
    arg1: "/C/Rebol/UniServe/protocols/DNS.r"
    arg2: none
    arg3: none
    near: [do any [get-cache file file]]
    where: 'do-cache
]

Why should it be looking for dns.r when it should be inside the cache?

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.