World: r3wp

what does that mean?

I build REBOL apps, databases, UIs, scripts. If I want some kind 
of web access to that, Cheyenne is key. I don't see Cheyenne as just 
another web server.

I have been loath to push Cheyenne much because of the freezing I 
was seeing before.

Dockimbel, let's say R3 was done and most bugs were squashed, would 
you then build Cheyenne for R3 and would it be from scratch?

the inability to run more than one Cheyenne server at the same time 
has been a problem too.

I didn't saw such "freezing" since september 2008 (the last one that 
happened here). I guess that the last fix about IE POST issue was 
the last possible cause of such problem.

I don't see it anymore because now I use a Rebol client to access 
Cheyenne and not a web browser.

R3: when it will be feature complete and in final beta stage, sure 
I will. I'll probably rewrite complety the lower level networking 
code and try to keep as much as possible the higher level code.

what role would uniserve play, if networking is completely async 
and threading is possible in R3?

UniServe is a thin framework layer other the raw port! stuff. It 
provides an event-oriented framework for implementing server or client 
side protocols. Some UniServe events are same as the lower async 
ones : on-connect, on-close. Other are higher level such as : on-receive 
(trigger when a given amount of data or a given sequence is received).

Did I mention I'd like to see a zope clone one day :)

response/Forward: This looks good. from the docs I see that it's 
possible to forward to a new RSP page. Will this work with a SHTML 
page as well?

did you mean ssi ?

graham, you can run MANY cheyenne servers on the same system .  and 
they can be handling several thousand requests / hour each without 
failure.  


at my client cheyenne is probably the most stable server application 
they have, a part from apache.

UniServe still has a purpose in R3, but it implementation will be 
much lighter and it will run much faster. Btw, one of UniServe's 
plugin, Task-master, is in charge of running and exchanging data 
with external processes given true multitasking abilities to UniServe's 
based products (RSP scripts are evaluated in such helper processes). 
R3 multithreading will make multitasking much simpler and way much 
faster.

Robert: never tried, but as it loops over the whole HTTPd request 
processing pipeline, I think it should work with SHTML.

the mod for access refusal is finished btw.  it works really well, 
I ended up doing it in a mod and doing a few invisible actions within 
the make-response and task-done callbacks.

Max, you don't get any errors when you run more than one instance?

Graham: I'm putting this issue higher in my todo list, shouldn't 
require much work to make it fully multi-instance safe.

nope... no errors.  the only issue is the Rconsole, but they don't 
use it.

and obviously, you musn't have two servers with the same ports.

graham: what kind of errors are you getting?

I ignore them :)  But I think logging is one

as Henrik said.. cheyenne was certanly rebol "web-window" for me. 
The day I tested and saw it can handle 300req/sec I switched to rebol 
for webdev.. there is no way I would use ordinary CGI to make webapps 
at this time.

for me too. = for me.

Graham: qwikitodo has close to 100 todos so it's "finished" although 
it will keep evolving, but it's a small project

that said, if R3 provides the capability of producing a really good 
webserver in 5 kb, I might use that instead.

then I predich cheyenne will be really really good webserver in 4kb 
:)

henrik: "that said, if R3 provides the capability of producing a 
really good webserver in 5 kb, I might use that instead."
what do you mean?


a webserver is not just about tcp/ip.... its all the framework it 
provides.  supporting the full range of reply errors, plugins, proper 
headers, etc , etc.  you can't really make that kind of thing in 
5kb.

Well, maybe you can't. I haven't given any thought to what it takes. 
I was only thinking of the basics like large file transfer and proper 
working async ports and threading. some basics that a good webserver 
can do.

right now, I can tell you that cheyenne, from the client's point 
of view, does all of that.  R3 will just allow it to be a bit faster, 
probably a bit more robust at the seams, and definitely easier to 
support, since some of the workarounds will now be implemented directly, 
and whatever is missing, doc can add/fix directly in binary.

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)