World: r3wp

I'm adding a lot of debug options within the config file directives 
right now... would be nice to be able to give an interactive face 
to those options  :-)

Pekr: maybe, never tried such approach. ;-)

(for remark that is)

View debug panel: definitely a useful tool.

Doc - old story - need .html to be called thru central dispatch script, 
or the index.html can't be dynamic ...

pekr, remark will be doing this by days end.  specifically, the file 
is parse once, until its saved out and cache is older than source. 
 once processed, normal cheyenne will continue with remark simply 
handling the url-to-file callback.

Pekr: it would not work that way, the CGI handler in worker process 
will try to DO the file.

ok I looked at web apps... remark is basically an uber web-app architecture... 
all it needs are a few more configs.
I'll add this in the second release of the mod

pekr, why not just specify the index to be an rsp script instead? 
since it seems to be dynamic in the first place?

default: index.rsp

sorry... bad syntax above...

default %index.rsp

I want to thank you doc for this exceptional piece of software which 
is cheyenne.


I have been playing around with it for months, on and off, at varying 
levels, and its always been able to cope with my client's and my 
own needs. 

Both in capacity and how flexible it is to adapt and extend to custom 
server requirements.

Max - never mind. If I want to use only Cheyenne, it is not a problem. 
I was thinking around the lines of producing rebol aproach, which 
would be interchangable easily between Apache and Cheyenne, for those 
who can't afford to push their provider to run Cheyenne for them. 
So I thought that following Apache equivalent would be useful. But 
my request surely is not a priority ....

AddHandler rebol-cgi-dispatch .html
Action rebol-cgi-dispatch /cgi-bin/rebol-cgi-dispatch.cgi

Max: thanks for the cheering up. :-) I've been also quite satisfied 
by the way Cheyenne evolved, a lot of thanks to patient users who 
report issues and propose fixes or new ideas. I wouldn't have got 
so far without community support!

Pekr: that's in my todo list, I just need to find some free time 
to think more deeply about how to support such feature efficiently.


Btw, I have built a XMLC (XML Compiler) engine inspired by enhydra 
(http://www.enhydra.org/tech/xmlc/index.html) which should fit perfectly 
your needs. It's a working prototype but need some significant work 
to be integrated within Cheyenne, so it's low priority for now.

well... the main call to remark is ... compile   hehehe...  I do 
plan on making an XML document model eventually.  basically, it would 
convert XML elements into your current Remark document models, so 
you can leverage the same code base but with another data model as 
input.


optionally you could build direct XML document models for a bit more 
speed.


all that needs to be done to make it easy for you guys is to build 
a few simple base XML tags which allow you to build the dialect based 
on xml element names.

Doc - do you have any feedback from outside the REBOL community users? 
Are there any?

I run Cheyenne as reverse proxy, which works very well.

And, I agree it's a very nice piece of software.

Only from close friends living in the java world, beyond them, no 
one. I don't expect much from outside REBOL world yet, Cheyenne is 
mainly useful for REBOL programmers. Once it reaches 1.x, Cheyenne 
will have features that would make it more interesting for outsiders 
(like a simple web control panel, web sites and webapp packaging 
in one unique executable, on-demand ready-to-use web application 
loading from our servers: blog, forum, bugtracker,...). I may also 
add a FTP service in a future 1.x version and a lot of other innovating 
new features I have in mind. ;-)

I'd like especially to make it a one-click solution for corporate 
users that need a blog, wiki, bug or task tracker,etc on LAN.

I honestly hope that remark can be a driving force for cheyenne btw... 
remark was never designed for rebolers.  the fact that its tightly 
integrated into html makes it very appealing for non-programmers, 
as well as the fact that it can use rebol's extremely rich datatype 
system.

I see it as the next evolution of markup no less.  It just happens 
to use Rebol as its scripting engine, but it could, in fact be adapted 
to other languages as well.

Is there a XMLRPC service available from Uniserve?

I don't remember seen one.

I thought you had mentioned some years ago you were going to write 
a rpc service ...???

Really? I don't see the need for one (at least for my own usage).

yes, it was supposed to replace Rugby and/or R/Services :-)

That's what I remember as well.

Digging into UniServe's repository, I've found one : RMC service 
(Remote Method Call). Can't find the client part thought. It was 
just an exercice to test the concept, never used it, so I've forgot 
it totally.

:)

Pekr and my memory appear to be accurate in this case.

It's equivalent to Rugby but without encryption. R/Services is much 
higher level. If someone is interested, I can search my older backups 
for the whole thing.

I don't need the encryption as it will be used as localhost

So, yes, I am interested.

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.