World: r3wp

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.

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.