World: r3wp

Maybe I could access mail functions that way instead of via rsp ?

It should be possible.

and feasible?

http://softinnov.org/tmp/rmc.zip

It will be harder than I first thought. RMC relies on worker processes 
to execute code, so it doesn't have access to main process.

Code is 7 years old, not even sure that it will work out of the box 
with current UniServe.

Btw, you might have a look in UniServe/clients/rconsole.r. It should 
be easier I think, to modify this script for your needs than RMC.

Humm...RSP's send-email function is in RSP space (worker process). 
It will be difficult to access it directly without going through 
HTTP.

I'm afraid that the only simple way is to go through http://localhost/email.rsp

How do worker processes differ from the main process?

main process = Cheyenne/UniServe
worker process = client of UniServe, no server.

Are database (ODBC) requests serialized when using RSP ?

Doc, I have a question, and possibly a suggestion based on the answer:


is there a way to tell cheyenne  to HALT when it finds ANY config 
error?


I have been having a lot of problems that where due to the config 
not being ok and me not seeing the (shy) error message... 

currently, cheyenne starts and its in an invalid state ultimately 
doomed to failure and without a clear way to determine what's going 
on when the requests do strange stuff.

although HALTing is mean, it also ensures your server is stable and 
you are forced to fix the config.

No way currently, it's a pending issue. The policy to apply is not 
that simple, I may agree on halting when the server starts but how 
to handle the case when you reload config when the server is already 
up and running? I would prefer the server to keep running with the 
previous config file rather than halting. I'd like to handle the 
config error loading case in a consistent way if possible.

I agree, but its mainly on initial start where it bites you the most. 
 cause when you are doing development, you'll edit the config and 
re-start the server anyways to be sure its ok.  right now its easy 
to miss... and I've lost some time debugging issues which where simply 
caused by the config not having been updated according new options 
or changed resources.

one question, does reloading the config also reload the mods?

It restarts the mods (calling mod/on-reload and mod/on-reloaded events) 
but it doesn't reload them from disk.

mod/on-started is also invoked during that restart.

Caching service for Cheyenne http://reboot.ch/rebol/cache.r

how does it work?

sorry I jumped the gun a bit hehe... firefox showed it without new 
line... but I'm looking at the source with newlines now..

can this be used outside of rsp?

sure

changed page to text/plain .. 8)

hehe

I have pretty steep requirements for the remark caching engine, but 
I'm gearing it towards long-term file caching, I was defering any 
RAM cache to a later date... funny how you pop up with such a thing 
right now :-)

I'd need a /time refinement returning what the date of the cache 
entry is for sure.  cause many cache conditions are time based in 
remark.

is that something which can be added to your service?

if so, I'd be very tempted to use it pretty soon. within a week probably.

can be done easly, source is in your hand , do whatever you want 
with it, sorry I have no time this week and I see no use of timestamps 
in rsp usage, but if I get at least one more same request I will 
add it 8)

also I'm wondering if compression should be an option, for small 
values it is an overhead..

it would be very usefull for me... the cache engine may actually 
cache the whole page if some cache keywords are at the top and bottom 
of a page

ahh, ok, I saw it the other way round... it always caches in it current 
form...

(after looking quickly at the source)

the cache service check for the expiration itself

in remark there is no need for an expiration... the whole engine 
knows if something has been refreshed, based on your conditions.

you give it a time to live and a block if its expired, the block 
get executed and cache updated

I'm not going to compete with remark, but I'll be gladd to look at 
it once you release it 8)

ah that's a nifty idea. :-)

I want to use anything that is out there... your service is a low-level 
construct I can surely leverage... I'll probably add a few refinements 
to it when I finish the caching engine... right now I'm dealing in 
other  lower-level remark internals.

(self modifying parse rules which adapt while parsing the file... 
a lot of fun :-)

the kind of stuff I'will never understand.. 8P

hehe... its taken me years of practice to get at this point.  I'm 
not a "natural" parse guy.

I wonder if this scenario makes sense.

Instead of having a complicated cheyenne/rugby hybrid ... we just 
use the rsp engine.   When the first client starts up, it uploads 
all the necessary sources for the functions it needs.  cheyenne then 
makes all these functions available to its worker processes ( perhaps 
storing the sources in its virtual disk cache ...

Subsquent clients can then use these functions via rsp ..

that lead to a enormous security problem no ?

Not if you secure the client.

Getting an error trying to get php running with cheyenne.


Works fine on xp pro but on mt win server 2003 box I get a dialog 
saying "apppication is configed incorrectly. Reinstall may fix..."

(I get this when I try to run php from the php icon. In xp pro I 
would get the dos box indicating that is was running) 


I know its nothing to do with cheyenne but has anyone seen this...
php is not installed