World: r3wp

The source version worked without any patches already.. I can't apply 
them to binary version because I can't enpro it.. I am still not 
an owner of Rebol or SDK

I could encap a new version if you need, just let me know which encapper 
you prefer : enpro or enface?

If I understand right enpro is without view and enface is not.. I 
would need the one without

That's right. Enface requires a few additional libs installed in 
order to work (like Xlib).

I would be really gratefull if you could make new build :)

DEBUG: I tried the debug-banner stuff but it doesn't work.

** Script Error : debug-banner has no value 
	** Where: rsp-script 

	** Near:  [debug-banner/active?: yes

Prefixing it with debug/ doesn't work as well.

Any idea?

Tested here, same error as you. The word is declared inside an object 
and is not exported in global space.

It looks like it's more complicated to activate the debug mode from 
within a RSP script than it seemed first.

Ok. I use the workaround that I'm logged into the server and use 
a "tail -f trace.log" to see what's happening.

Works.

doc, my I suggest a new feature?

sure

a way for a service to be asked permission to allow connection from 
the uniserve POV.

something like on-allow-connection? within the service api.

can services add data within the /shared object?

this way, the uniserve can ask the service if all is set for handling 
requests... there are hundreds of uses for this... time tables, required 
header fields, etc etc.

in this case connection limits based on service specific requirements, 
like detecting deadlocks in requests ... which uniserve obviously 
can't figure out by itself.

if the service is in an state it can deduce as problematic, it can 
directly report it to the client attempting to connect to cheyenne, 
before any data is even read.

in my case, the services have dependencies on remote servers... so 
its possible the remote server is down, I want to report this to 
the client connecting to cheyenne right away, not wait for a double 
timeout to occur, which means the service can be down for a very 
long while before cheyenne client connections start reporting error.

in this case, I can easily keep statistics on my service, noting 
access times and concurrent connections, detecting if something is 
preventing the service from actually handling calls.

Shared object: yes, you can add data there, it's for sharing data/code 
between all services.

Is it possible to load a SSI page from a RSP script? I have the following 
situation:


A RSP page is triggered by a link using a virtual  REST URL. Now 
I need to return a page to the client in a way that the URL bar of 
the browser shows the virtual REST URL. The page I want to return 
is a SSI page.

is there docs on how to store shared data?  (note I'm a cheyenne 
noobie, even if I now know how the request is handled from client 
down to internal service handling hehehe)

doc, if you want I can implement the new feature and give you the 
part of the code which was tweaked?  is that usefull to you?

SSI from RSP: you can load it, but it won't be processed. There's 
no buitlin way to process SSI from RSP, but you can extract the processing 
code from SSI.r and load it in your RSP to do that (maybe not the 
simpliest solution...).

I'd have to ask permission from my client but I don't think he'd 
mind.

Docs on shared space: http://softinnov.org/rebol/uni-guide.html#sect4.7.

thx

Would it be hard to add a SSI-INCLUDE function that's available in 
RSP files?

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.