World: r3wp

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.

it has the advantage of freeing the load from the web server so it 
can continue to stream data... and some client work using several 
inter-connected cheyenne servers actually provides good results, 
so I'm optimistic so far  ;-)

Doc, I don't know a lot about this subject so sorry if I ask stupid 
questions :) ... could it be made and would cheyenne benefit from 
using IPC like pipes to communicate between processes instead of 
TCP ?
(I used pipes just once so far so I don't know much about them)

BTW.. did any of you see the recent discussions about Unicorn ( a 
pure Unix philosophy webserver - that uses pool of processes .. etc.. 
very interesting blogposts in any manner, I can find links if anyone 
is interested. It reminded me a little on cheyenne too, although 
Unicorn has no async I think)

janko yes, IPC is another way to approach the issue, but the question 
is how easy would it be to use within R2?  have you successfully 
done IPC stuff within REBOL using a dll?

Pipes implies the same overhead of serializing data to be able to 
exchange it and AFAIK they  cannot be made async in REBOL (polling 
could be used instead but would affect whole server performances). 
Regarding session synchronization, it's the same complexity than 
TCP.

Doc, have you ever made benchmarks of TCP xfer rates between two 
process, using Rebol?

integrated mod-remark in BIND directive  :-)

Doc is there any documentation on the directives dialect?

Dialect: no, but you can have a look in %mod-static.r, there's a 
lot of examples there.

I just don't see where some of the setup gets put...  for example...


[remark-debug in main]  .... hum... where is that information stored?

benchmarks of TCP between two processes : no, I never needed to mesure 
that speed because anyway, I don't have real alternatives.

main => directive has to be in domain or webapp config block
global => directive has to be in global section of config file

'location and 'folder targets are currently unsupported.

but I mean where does the information end-up?

loaded configuration file can be accessed from mod functions using 
this path: service/conf

Additionnaly, from mod functions, you can get your domain or webapp 
config block using req/cfg (you don't have to search in  the whole 
config file which part applies to the request, it's already done 
by Cheyenne).

ok... with this info I've done a few tests and I see the config files 
allows you to dump pretty much any thing anywhere... is the  'in 
keyword only for the 'do to be recognized within one of the setup 
blocks?

ah just noticed a little "conf-parser" error line within the wealth 
of prints on startup  :-)  I see my previous statement isn't quite 
true  :-)   hehehe

if you're accepting ideas for cheyenne... it would be cool for the 
conf dialog to allow us to add items in the systray, which fork to 
a system event within the mod.  many uses for this come to my mind 
 :-)

is there any documentation on the concepts of web-apps?  is this 
an rsp-specific cheyenne concept?

can I get a login for cheyenne's website wiki?  I would love to help 
you out with the docs, as I build up my mod...

extend tray icon menu from mod : good idea.

seems doable.

I'd use it to switch debug modes in real-time... and maybe even build 
a small view config/debug pane, if I detect a view version running 
cheyenne.

very usefull for development cycles  :-)

Webapps: you can find some docs in the Java world (look for JSP/Servlets), 
concepts are similar to RSP webapps. See http://caucho.com/resin/doc/webapp-overview.xtp

View debug panel: I thought about that too a while back, never had 
time to try that concept.

doc - could bind or bind-extern be used to invoke CGI handler for 
.html files?