World: r3wp

ah, so I really don't understand guys' point on ML, complaining that 
web-hosts are REBOL unfriendly. I tried with two, and those had no 
problem uploading rebol for me ...

What I have found to be a problem is accessing MySQL accounts from 
client based rebol scripts. They seem to only allow server based 
access.

amacleod. And how?

With one host, I e.g. have: /home, /www, /tmp, /logs ... should I 
put into /home?

indeed, i think they are just lazy, and want rebol to work out of 
the box. they just have to upload it. it will work with 99% of the 
hosts right away. and the host should be able to easily solve that 
1% case, unless they are morons and only allow php etc. by policy.

yes, /home, maybe /home/bin or something like that. (/home/rebol/... 
would be ok too)

But other hosting my friend has, is just and only his www root ....

Gabriele - exactly my opinion ....

mysql: some hosts only allow socket access and not tcp access to 
mysql (because that's the default config for some distros.) but, 
that's something that they can enable without problems.

I have a rebol view app that I use to acces a MySQL database. I had 
it working  and then ,y ISP decided to add security and no longer 
allow MySQL access unless its a script on the server. Ofcourse they 
did not inform me and it took some time to track down the problem..

That is why I was trying to suggest to rename rebol to some AAAAAAABBBBBBBCCCC 
name, unpredictable, so it will get hardly noticed, even if someone 
would try ... (unless you do some bug and your shabang line gets 
reported back to browser :-)

www root - well, you can put in www but outside cgi-bin, so it can 
be downloaded but not executed. or, worst case, hopefully they allow 
you to put a .htaccess to deny access to rebol itself.

At least that was the explanation I was given...\

OK, I feel I miss knowledge on Unix permissions. So if cgi-bin dir 
as a whole has execute bit, everything in there can be executed? 
Hmm, and don't I need execute bit for rebol itself, even if put into 
other directory?

it's not execute bit of the dir, and it has not much to do with unix 
permissions, it's web server config. normally, web server will only 
execute things from cgi-bin and not somewhere else.

eg. in apache you have ScriptAlias directive to tell it where to 
allow executables.

aha, ok ... so, if I put REBOL into other dir, even if it has execute 
bit in order to be runnable, Apache will not run it, as directive 
for the directory does not allow that, right?

exactly.

but then it will be probably downloadable :-) www.domain.com/some-other-dir/rebol

but maybe it could be prevented to be seen by setting some .httaccess 
option ...

yes, it will be downloadable unless you deny it with htaccess, but 
that's usually not a big problem.

Petr;  DON'T  :)  Suggesting that people try and sneak REBOL past 
sysadmins is a really really really bad idea.  If they can't be convinced 
to try it, then change ISP, or try to convinvce them again.  Don't 
be making REBOL look all cracky.   That is the kind of maneuver that 
could sink the ship.  The rest of us like the ship, and we fly the 
flag of peace and truth, not the Jolly Roger.  :)

My uplink speed kinda (no, it pretty much completely) sucks but I 
offer free hosting to any rebol that wants it at peoplecards.ca. 
 I just ask for patience if a new service needs to be installed while 
I work out kinks and the user needs to know that it's home based 
with a not-so-speedy delivery pipe and I offer little in the way 
of frills; meaning it's sftp or ssh cli, not cPanel or other gui.

We fly the flag of peace and truth
.. hummed to the tune of "God bless America"

Don't forget the great big smiley...

Is that the tune that  sounds like "God Save The King?"'   If there's 
a sugar maple blight, 'The Maple Leaf Forever' will sound lame ... 
and they'll never see the Eastern Townships annexed by Vermont.  
'CGI'  does stand for 'Chat Gateway Interfarce' doesn't it ?

Anybody noticed CGI is back as a programming model?

Let me explian.... (the PITL in user.r reminded me to post this)....

First - do not virtualize OSes

1) Think multicore
2) think memory is cheap (2Gb per core)
3) Typically,  /Core  consumes 8 mb of memory

4) do not encap, use  amodule management system like my 'require 
or Ladislav's 'include

5) wrt 3 and 4: the OS starts using its disk cache etc. After a few 
hits these operations will be cheap

6) do all session mgt etc in a database => sales up as well, no state, 
share nothing

Now, what happens? The OS will start distributing the CGI processes 
over the multiple cores. Using the disk cache etc to speed loading 
times, enough memory per core on the processor. A 8Gb RAM quadcore 
should be able to run +- 1000 procs/sec (rough estimate). That's 
just one box, with that load it should be profitable. And as you 
obey rule 6, you can scale up and load balance pretty easily.

Winding down: Apache CGI with RSP is pretty good these days. If you 
combine:
- module management
- logging
- error handling
- session management
- database protocol (mysql://)
- CGI params handling

you can "just work".

not virtualising OS this days is imo a mistake, no? :-)

depends on what you gain

Are you sure OS distributes CGI processes to different Cores? Is 
e.g. Apache working that way?

If they are separate processes, the OS should balance over cores.

Gregg: really? I thought that the reason why R3 will use threads 
for tasking instead of tasks is, that OS can better balance threads? 
Anyway, those questions are for gurus, I can only wonder :-)

Threads are much lighter, but not as separate. I don't know details 
though. On a dual core with hyper-threading on, spawning multiple 
processes, I can see the load is spread.

petr, the processes are managed by the OS too. *obviously* the os 
will distribute processes among processors. (unless the os has no 
multiprocessor support, that is). distributing threads is more difficult 
(because of the shared memory), however all good threading implementations 
should do it, and if you programs the threads correctly you can get 
the performance boost.

Can anybody give me an exampkle setup + explanation of FastCGI + 
lighttpd with FastCGI; also on the Rebol side. I know Francois mentioned 
it was easy but I don't get how you can do adaptive spawning one 
the same listening port (e.g, 10 Rebol FastCGI processes listening 
on port 1026 or so)

I used fastcgi in the past, wich Apache, under linux. All modes worked 
fine IIRC. However, under windows, the implementation was crippled, 
and only external mode worked.

Also, there was problem, that the same client could be served by 
different process, so fastcgi guys implemented some kind of "afinity 
patch", kind of proxy, which then connected the same client always 
to the same process.

I don't think those 10 processes would listen on port 1026? In fact 
I don't know, how it is being done.

Hope you read http://www.rebol.com/docs/fastcgi.html

That REBOL doc should really answer your question. Simply put, in 
External mode, you do something like /path/to/script (that does not 
need to exist) and you direct it to certain, already running REBOL 
process. But - rebol has no tasking, so you have to handle accepting 
connections and multiplexing. It is like with Rubgy - unless you 
are finished, you are not available to other requests ...

Read that, but that is why the adaptive scaling with lighttpd is 
interesting if you put number of request/fcgi porcess on 1. Then 
the daemon scales for you

Maarten, I agree with your observation and you can even scale it 
more.


If you see a web-server as just a request dispatcher to CGIs and 
a fast-answering-machine for user-feedback (pages, forms etc.) you 
just need a small and "simple" one like Cheyenne. The CGIs can be 
distributed to different cores (through the OS) or even to different 
machines (via TCP/IP).

As dispatching requests is most likely much faster than processing 
a request, a single web-server should serve a lot of users and a 
bunch of machines do the processing.

This is the coarse grained multi-process approach.

With Cheyenne you can already have the main httpd process on one 
machine and task-handlers (RSP or whatever) on other machines 8)

I am close to autogenerating fastcgi processes, linked with Lighttpd 
configs and generating automagical includes that match the web server 
config  for encap/Pro.