World: r3wp

The bugtracker will be fully open sourced and will also serve as 
demo of a complete online application done in RSP with a DB backend 
(MySQL currently).

cool

I'd say GREAT! the live patching was a real adrenaline experience 
8-))

great news.

I always love your work :)

Love it!

Look forward to your new release. Keep up the good work!

Thanks you all, guys, for your enthusiasm! :-)

looking forward to trying it. will Cheyenne be R2 only?

So RSP and sessions are already working? That's cool! Top quality 
http server which does not need to be installed!

And I am loooking forward to compare Cheyenne R2 vs Cheyenne R3 (using 
threads), and to see speed, and system resources requirements :-)

about R2, have an ajax app with db calls (ok mysql +query cache enabled) 
, 200 reqs/sec brings a dualG5 2GHz at 80% cpu pretty fast 8-)

isn't 200 req/sec job for some server, than desktop machine? ;-)

ah, misplace RSP with RPC, heh :-) RSP - typical old model :-)

now that Cheyenne is ultrastable on heavy traffic, I'm more looking 
forward to a Intel native rebol for os x running on a 8core xserve 
than a R3 version ;-)

why? Shouldn't R3 be just more async and shouldn't threading be there 
to provide us with better scaling?

btw - could I do following? Set my .html files to be treated as CGI, 
via some handler? I can't stand using mixing templates with html 
codes, especially in that manner, where your template code ruins 
normal browser display ....

still looking forward to a faster R3 version, shouldn't be to hard 
to add machines and distribute task-handlers , and if the main process 
get too busy, put a lighthttpd proxy in front.

not sure I understand but you can set .html in config to be handled 
by rsp

I simply want my index.html (or other) to be submitted to mine registered 
cgi, which I call rsp.cgi. This "dispatcher" looks into list, if 
this page is registered as dynamic, and if not, returns requested 
html page directly, or scans it for module names, which are then 
loaded and know what to do. I simply want my gfx man to have free 
hands, not requiring to fill any rebol code into templates - just 
marking sections ...

you could pretty easly write a mod, you may able to do that with 
mod-rewrite which get called in the url-translate phase

ok, fair enough, thanks :-)

Doc: will Cheyenne also be available as source and Linux binary (and 
FreeBSD)? If you need help whit encapping, let me know.

Yes, it will be released also as binaries in separate packages (apart 
from the source code package). I already have binaries for windows 
and linux, i'll be glad if you could encap it for FreeBSD.

Is it wednesday in Europe yet ;)

Btw, the encapping system for Cheyenne is a little odd : to be able 
to run it in normal mode and encap mode without changing the source 
code, I wrote a special lib emulating the filesystem but in memory. 
I didn't had time yet to check if Ladislav's Include could do the 
job. My encapping system needs to generate a .encap-fs file, so it 
needs that Cheyenne be run in normal mode at least once. I'll document 
that in a few days.

Terry, not yet ! ;-P

Cheyenne early release 0.9.10.0 (source code only) : http://softinnov.org/tmp/cheyenne-r09100.zip

See Cheyenne/docs/rsp.html for the new RSP API (the doc is half complete, 
I should finish it tomorrow and add a CSS)

Im looking to run my Uniserve service along side of Cheyenne.. using 
a particular port.. but the one last thing i need to do is pass messages 
from the httpd to the service.. will this be trivial?

Cool

I also add a general manual for setting up Cheyenne and basic CGI, 
RSP and Session concepts in the next days.

I also -> I'll also

Thanks! This makes you an official REBOL hero.

Terry, in my todo-list, I have a generic module for interfacing cheyenne's 
HTTPd with REBOL applications called mod-map-url (or mod-mapping). 
It will map predefined URLs to REBOL objects. Example: http://domain.com/app/show
will call the function ''show from your object 'app. This module 
should cover most of needs if you have to embed Cheyenne in your 
REBOL application. If it doesn't cover your specific needs, you'll 
have to write a specific mod_xyz HTTPd module, which might be a little 
more complex.

Louis: thanks, releasing a new version is like winning a battle (against 
all those evil little details!) ;-).

Yeah, not so much a URL.. but a message.. I want to be able to push 
to the browser.. client logs in, we grab his IP, pass this to the 
rebol script that can push to a receiving JS script.

In any cases, HTTP communications involve a request from the client, 
so it implies an URL...unless your JS is not using HTTP protocol 
?

Wrote our own.

So your wrote your own UniServe service to answer to JS scripts requests 
?

Um, no.. I wrote a uniserve service to push messages to a flash script 
embedded in the page.. the script then passes the message on to JS

You can use the uniserve's shared space to share data and functions 
between services (anyway you'll have to add a specific module to 
HTTPd to be able to exchange data through the shared space, HTTPd 
is not exposing any function nor callbacks to the shared space, but 
it might be a good idea to add such feature...).

I hacked your HTTPd somewhat to 'intervene' .. just wondering if 
there was a purer method.

Ok, I see now :-) You could use the REBOL plugin instead of Flash 
to achieve that, but I guess that you don't want your users to have 
to install any new plugin.

exact.. especially not the rebol one  (way too buggy)

flash works great.. did you see the RASH windows demo .. I embed 
that into a page, and push data to it from my uniserve service

The current clean way to extend Cheyenne is to write a mod_xyz module. 
The module specifications are documented in Cheyenne/docs, and your 
have several examples in Cheyenne/mods. I can provide some additionnal 
explainations through this altme channel if needed.

your -> you

great thanks

It's not that hard to write one, the hard part is to correctly set 
the execution order for each callback (each module competes with 
all other modules for a given callback event, and you have only 3 
possible positions, 'first, 'normal (middle) and 'last.) The loading 
order of modules in the config file (httpd.cfg) also impact the final 
order of callbacks execution. I plan to move to a much more simplier 
system for Cheyenne 2.0, it will loose some little flexibility, but 
it will be much more easier to write extension modules. But , that's 
long-term, i need first to reach 1.0 ;-).