World: r3wp

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)

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.