World: r3wp

Most of Janko's new products are Cheyenne based.

I don't think they're finished ...

Part of Will's company main product is using Cheyenne.

didn't know that ...

I thought he worked for a company .. didn't realise Rebol was important 
in that way.

A few small intranet apps in a couple of TOP 5 french company are 
using Cheyenne and RSP.

Sorry, yes it's for the company Will is working for.

I did release my Hylafax web portal which I know a few people are 
using :)

And we have also a big product using Cheyenne/RSP with already a 
few dozens customers.

what does it do?

I prefer to keep it "under the radar" for a few more weeks. ;-)

who's radar?

Microsoft?  :)

I'd like it would be *that* big. :-)

I did build a web portal to my medical database .. but too busy to 
keep that going.  Have to learn a lot more jQuery ....

Still, I have a few users of that as well.

that's what I use for filling in Acrobat forms programmatically.

So, that's you, me, will .. possibly Terry.  Anyone else?

I see Cheyenne as a web-window to REBOL apps.

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.