World: r3wp

apache coders would already be jealous at how easy it really is to 
build a mod right now... even the configs can be specified within 
the mod with a few words.

Having the TCP/IP part open-sourced in R3 will be great. It will 
allow to use much faster OS hooks for file transfers, extend the 
port! API to bind only on selected interfaces, etc...I wonder if 
the main event loop will be there also, so we can replace the not-scalable 
Select( ) call by other faster ones or even integrate libevent. That 
would definitely make Cheyenne able to handle a much higher number 
of connections.

:-)

for my part, when R3 goes open, I'll be integrating liquid-paint 
with OpenGL asap... which will completely alleviate my need for /view. 
 we will have a 3D native GUI  :-)

bringing it up to the best servers speed wise will get people's attention.

Not just the TCP code will be open in R3 - the HTTP port code will 
also be open. One of the goals is to make something like UniServe 
completely unnecessary for R3. This is not a criticism of UniServe, 
but of R2. If R2's networking infrastructure were good enough we 
wouldn't need UniServe.


Hopefully by the time that Cheyenne is ready to be rewritten for 
R3 it will be able to be written right on R3's HTTP ports.

HTTP port code will also be open -> HTTP port code *is already* open

BrianH: the HTTP R3 scheme is client side only  or did I missed something?

I agree with your comment on UniServe to some extent. I'll see when 
R3 will go beta if I can remove that layer.

libevent was suggested in the past, along with links to liboop etc. 
Not sure the licence is OK. Anyway - I wonder where do we go such 
a way? I can already imagine complete mess and tens of versions of 
custom R3s, if such low level things as main event loop are open-sourced 
and replaceable.

Doc, the intention is for the R3 HTTP scheme to also support http 
server use. However, the current HTTP scheme is just a placeholder 
until someone can update or rewrite it. Client use is jst what (barely) 
works in the placeholder.

Gabriele wrote the current scheme, then stopped to work on other 
stuff. We're still waiting for someone to pick up where he left off.

Perhaps someone who has already written a kick-ass web server... 
:)

If noone steps up I was going to rewrite it myself, likely based 
on Cheyenne - thanks for BSDing it, btw.

That would require me to get a round tuit though.

pekr, who cares if there are 2000 versions of compiled rebol out 
there.   RT's is always going to be the default, and all the rest 
will be purpose built.  at least now we can play with any other tool.

for example, i know of a server which profiled the tcp stack of their 
server and realised that some buffer sizes didn't get cached the 
same way through windows.

just changing the size of buffers and tcp payloads added a big speed 
boost.  stupid detail, but now if we have such cases, we can actually 
really go as deep as that.

BrianH: how do you want to bring something like Cheyenne (Uniserve) 
to R3, if such low level stuff as concurency is not designed yet? 
Wouldn't it (using tasks or not) influence its design? So do we wait 
for new R3 concurency model, or do we proceed with protocols, and 
rewrite later? (we can move to R3 chat instead)

Brian: that's interesting, but as you can guess, my free time is 
currently very limited. Maybe we can work together on that? I think 
that your input (especially with R3) would be of great value. I agree 
with Pekr for the dynamic part of the server, without tasks, it will 
be good only for serving static files.

I would only have one request for Carl to switch me to R3 (feel free 
to copy that to R3 chat) :

Please plug back in the Windows REBOL console device in R3!

Doc, we should talk more about this later, in particular wjat you 
meaan by the console device. Must sleep now.

BrianH: I think that what Doc means by Windows console is R2 kind 
of console, not that ugly black monster Windows offers you by default 
:-) There was lots of talk about the console topic and we imo need 
both - system default one, for admins, and GUI based one, for normal 
users. But GUI console could be created using View, as Cyphre showed, 
even in R2 it was nicely usable ...

Just played a little with DOS console parameters to try to make it 
look&feel like R2 console. Quite close so far (except for the font). 
Need to test it in action with R3 to see if I can use it for serious 
work. I'm very picky about the tools I use daily.

Yeah, the intention is that a GUI console will be written in REBOL, 
part of the community-created, open-source portion. Then you can 
use or adapt the console for your own apps as well if you like. How 
about having RConsole being implemented with that? :)


Right now the GUI doesn't have good-enough Unicode support to make 
the console yet, so the GUI console will have to wait for the release 
of the host code (the current priority), and the subsequent resumption 
of the GUI work.

Be sure to select the QuickEdit Mode and Insert Mode options for 
the DOS console - they make your life easier :)

.

How exactly does Cheyenne cache file loads? I have trouble getting 
a specific REBOL script to load.

I think I have found a bug where Cheyenne keeps serving an empty 
file, if I have first had it put in a server directory as a MacOSX 
shortcut and then replaced it with a real file of the same name.

Not sure how shortcut are handled by REBOL for OSX. The cached version 
is reloaded only if the file modification timestamp changed.

I'll investigate it further if I get the time.

is there a way to prevent caching and logging?

logging: See %changelog.txt (search for disable-log and no-log)

caching: no, why would you prevent that? There's several caching 
systems in Cheyenne: static resources, RSP scripts, some HTTP headers 
generation,...

cause I need to handle it myself in mod_remark.. is this part of 
the module api?

Depends on what king of resources you're talking about. Static caching 
is done in mod-static like most other HTTP header caching. RSP script 
caching is done in helper processes.

If you want mod-remark to take other mod-static caching, just provide 
a 'make-response handler in mod-remark, give it a higher priority 
and make sure to return a TRUE value (that will end the phase shadowing 
mod-static's handler for that phase). You can also just unload mod-static 
by commenting it inside GLOBALS section in config file (you'll have 
then to provide all the adequate handlers for serving static resources).

ok, that answers my question perfectly... the caching is handled 
by mods.  VERY cool.  :-)

Right, each mod can provide its own caching system if required.

the thing is that in order to save resources, mod-remark will be 
creating MANY static files (including images and css scripts) but 
the content of those pages can ultimately change at each refresh, 
if the user is editing preference type information.

Just remember one important thing : mods live in the main process 
(the one running UniServe), so you have to keep mod handlers fast 
enough to not slow down the whole server. That's why Task-master 
service and it's helper process are here, to handle the load for 
the main process. See mod-action as an example of unloading the main 
process from the burden of running CGI scripts.

yep.  I know all about the task handlers... they are one reason I 
was having difficulty tracking where and how dynamic code was being 
run in my client's app.   ;-)

in mod_remark, all that can be forked to the task handlers will be. 
   remark will be using liquid for many things, allowing the task 
handlers to cache just about every CPU intensive task which doesn't 
need to be recalculated.  I expect it to be one of the fastest dynamic 
web systems on any platform.

but testing will reveal if that is the case  :-)

Looks like you've gone really deep in UniServe. Sending job to helper 
processes has a cost (building message, MOLDing, transmitting through 
TCP, LOADing, decoding message). With R3 and multithreading, this 
cost will reduce to zero, thanks to shared memory (or equivalent 
system).

yep... I'm now pretty versed in how uniserve handle's its universe 
 ;-)

yep threads will be a big plus in R3... many apps are much easier 
to write with threads (of any kind).  it breaks up the domain of 
many problems into smaller pieces.

I have the following problem. Depending if I send via POST or GET 
the CONTENT is different.

1. POST: [paymethod "paypal" rest "payment"]
2. GET: [rest "payment?paymethod"]

Why this? Where is the VALUE part in the GET request?

I use code like this:

<input type="radio" name="paymethod" value="paypal" />
<input type="radio" name="paymethod" value="somethingelse" />

And this code is wrapped in a DIV.