World: r3wp

Max, not sure that it can help you, but you can open a live REBOL 
console connected to a running Cheyenne instance (only from localhost). 
You can then use the NETSTAT function to list all active connections 
in realtime. The client for connecting is : %UniServe/clients/rconsole.r

If you try that, just beware of a few things :

- don't use QUIT or you'll close Cheyenne, just send a CTRL-C to 
exit the console session.

- avoid probing things like UniServe's ports, they contains several 
circular references that, once molded, will produce huge amount of 
printed text and can hang on the server for several seconds (or minutes 
in the worst case).

rconsole is cool, it will allow me to follow development from the 
outside.

I mean follow if the changes are really doing what they should  :-)

I've use it a few times to hotpatch running Cheyenne instances.

<used>

Hi, Doc .. is the latest binary not totally the same as sources? 
It seems it doesn't look into lib32 like it does if I run from sources

It should be the same. Did you applied the patch I gave you in Linux 
group on the sources?

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.