World: r3wp

Robert, no, it shouldn't be hard I guess. Just extract the code from 
SSI.r and load it in your RSP. Btw, you can use the new WORKER-LIBS 
config options to load that code to be available for all RSP (standalone 
script or webapp).

Ok, cool. Will do so.

Max: I'm reading several times what you're asking, but after 11 hours 
of work today, I think that my brain is too "liquified" to get it 
at once...;-) I'm trying again.

heehehe

client connects ->  uniserve ->  service(httpd)/on-allow-connection? 

MSG 500: Remote server problems
 <-  uniserve <-  "Remote server problems"

Ok, I think that what you're asking for may be too specific for each 
services to be implemented in a general way in Cheyenne. Shared data 
(using shared object) might solve most of this class of issues (requirements 
to accept new clients connections).

Are you just asking for a new "on-allow-connection?" callback in 
UniServe?

I realise that an on-connection-error callback (in the service) would 
also be required to construct a proper reply, based on the service 
being called.

doc, yes....

sorry... I'm a cheyenne noobie hehehe still having issues knowing 
how to refer to some things in "cheyenne speak"

No problem, you can have a look into the UniServe documentation, 
to see what's already available.

this being said, I will be using a cheyenne server for my brand new 
web setup, using remark to replace rsp completely.  So I will build 
a remark-mod shortly.

Ah good to know. I'll be interested to read your feedback once you'll 
have remark integrated.

the main job will be to do build a set of tags which provide easy 
.net type form post back handling, without the need to have 15 scripts 
or  excessively complex php-like scripts to properly handle form 
data.

part of the integration will be run-time tag editing, so anyone will 
be able to build a CMS using remark, out of the box.

that is actually easier to do than the form stuff hehehe

About your feature request, I understand that your "on-allow-connection?" 
event would be generated just after the connection between the client 
and server is established? If it's the case, then you already have 
the "on-new-client" callback where you can decide to reject the connection 
or send back an error message if required (I often use it to reject 
connection based on IP adress access list).

aaah the docs don't make it explicit how the return value is used... 
I'll look at this more closely.

Btw, in UniServe context, "event" and "callback" are two faces of 
the same coin. From the engine POV, it generates "events" that result 
in calling appropriate "callbacks" in service handlers.

Welcome in UniServe's plumbery ;-)

hehe

I'll probably do the remark v3 as I am doing the module... so when 
that is done, plumbing will be quite literal term for uniserve wrt 
to the module   ;-D

I was afraid that you'll try to fit Liquid inside UniServe making 
Skynet and the Judgement Day happen earlier than expected and before 
I get the chance to see the new T4 ;-).

:)

hahahha

my name here is just a nick... my real name ends with connor   ;-)

is there a Mod document, as I realize I must handle the "on-new-client" 
callback within the mod's context.  that is where everything is being 
handled... so I might still need a little tweak to the cheyenne part 
of things within the httpd service.

In fact the UniServe's API is the low-level API. Cheyenne is implemented 
as a Uniserve's service (httpd) and exposes it's own higher level 
API for mods.

In Cheyenne source package, you'll find an incomplete mods API documentation 
(Cheyenne/docs/developer-guide.html).

yep... got that ... but can't find the docs for mods on the cheyenne 
site... since the wiki went on line, all pages are empty  ' :-/

ok, will look for it in an old download.

You can also look at the various mod in the source package (Cheyenne/mods/*). 
Mod-static is probably the most complete (implementing most of the 
callbacks). If you need to process the request in a worker process 
(multitasking), you can have a look in %mod-action.r for an example.

Latest Cheyenne source package is available here : http://www.cheyenne-server.org/dl/cheyenne-r0919.zip

thanks sooo much for keeping with me... I know its a redundant thing 
to do (supporting noobies all over again), but its really appreciated.

It makes a good opportunity to practice my poor english skills. ;-)

ironic, isn't it  ;-)

Is the database name fix in that ?

No, it's in the special release I've made a few weeks before (0.9.20 
beta).

Link was : http://www.cheyenne-server.org/tmp/patch-0920.zip

But I found a few bugs since then, so if you need it now, I can make 
you a snapshot release of the latest stable version.

Max: half-ironic ;-)

Here's the current changelog since 0.9.19 :

v0.9.20 - ??/??/2009


 o RSP: databases definition can now be declared at webapp level allowing 

   multiple instances of a webapp to use the same virtual database name 
   but,
	  pointing to different real databases.
	  

 o Config keyword 'databases now allowed in webapp sections. If defined 
 there,
	  it takes precedence over the global section definition.
	  

 o Systray help message now includes HTTPd port number used by the 
 running
	  instance.
	  

 o RSP: session security improved by binding client's IP address to 
 the session.
	
	o Fixed issue with loading %libc.so for Linux 64bits versions.
	

 o HTTPd: fix a long standing issue with IE5/6/7 extra CRLF sent randomly
	  after POST data.

The last entry was probably the cause of some of the rare "RSP freezing" 
issues. I've stumbled upon it recently while making a demo of one 
of our web-based products using IE7 through a proxy.  By default, 
IE7 switches to HTTP1.0 when connecting to a proxy causing the extra 
CRLF bytes after POST data to appear.

The issues I saw with Cheyenne were all related to IE and POST.

So, v0.9.20 is not released yet ?

Not yet, I'm still working on testing/fixing a few things and will 
add some minor features (like httpd.conf search path for Unix). Anyway, 
it should be out by the end of the month, I don't want to wait longer 
to release it.

All: If possible please hack all information that is useful for others 
as well into the Wiki. IMO that's the best way to build up a "documentation" 
for Cheyenne. And it frees Doc from answering the same stuff again 
and again.

What is this in reference to?

Doc. I have made a testing engine that simulates all sorts of http 
requests for testing my apps in rebol ... it so so works now, so 
I have to improve it still . .. you could also use that to create 
a pack of test suits for cheyenne and each time you make bigger changes 
you just run it and see if things behaved as suspected

Graham, you mean my post? Well, I thin Cheyenne is really nice and 
we should all help to make the docs better. And Doc has setup a Wiki 
for this.