World: r3wp

I'm adding words which are commands within remarks' module using 
the do variant of config definition...  this allows me to grow a 
config by calling the same command multiple times.... this would 
be very unweildy to implement any other way (but not impossible)...


maybe a function-based api could allow us to "hook" into the GUI 
but its pretty hard to cover all possibilities in any case... anhow... 
back to modulating remark.

There's a builtin "process" function in config DO blocks allowing 
to process nested blocks (see mod-static/if-loaded? definition).

It's not as powerful as it could be, thought.

ahh so that launches a new parse config on the block we give it?

Yep

when the config do is performed, I noticed you do a bind on the block... 
the thing I wonder is to what it is bound... its not obvious to me

It binds to the conf-parser object, because it needs (at least) to 
access the process function located in conf-parser.

k thx

Maxim, I tried with the port and it worked..thanks alot, but I could 
have sworn I had tried it like that too...

happy I was of help :-)

It should have worked even without the port number. It's a bug that 
will be fixed in next release.

Any reason why cheyenne does not allow a .r file to be read via http? 
It seemed to work with apache. I had to change it to a .txt file 
to get it to work..after batting my head for many minutes.

in the http.cfg file its assigned as a cgi script:

bind-extern CGI to [.cgi .r]

and the CGI handler will execute it.

you can change this obviously.  :-)

Thanks. I thought it might have something to do with RSP but I see 
it is even simpler than that...

It would be nice to have Cheyenne support UTF8, I have it working 
here with some functions provided by Oldes, utf8/length? utf8/trim 
but a proper html entity converter is still missing, I think Gabriele 
has it but that's on hold by Reichart.. 8)

of note, it's not "Reichart" that's holding it. it's just that Qtask 
the company has not decided on the license yet.

thanks for correcting me 8)

btw, has Cheyenne been considered for Qtask? if not why?

because they use PHP I'm guessing

Cheyenne does PHP, but indeed, the Qtask frontends don't seem to 
use REBOL

Cheyenne has been considered within Qtask, and tested in a test project, 
with success. The lack of server-side SSL is a deal-breaker for the 
main site but it is usable for supplementary services. RSP went over 
well too, so Maarten is updating the original RSP for use in Qtask 
(though not with Cheyenne).

because they use PHP I'm guessing

 - the promotional web site uses some PHP, but the main site is all 
 REBOL.

the Qtask frontends don't seem to use REBOL

 - You are correct, the frontends use Javascript, generating the usual 
 HTML and CSS. That Javascript is often generated using REBOL. Frontends 
 in REBOL are possible though.

Third party tools can be used to tunnel SSL, like stunnel or nginx. 
About RSP, does Cheyenne's RSP miss some features required by Qtask?

True about the tunneling tools, but I'm not the server guy so I don't 
know why they are still using Apache for the main site. I know they 
aren't married to it since the site isn't built on unique Apache 
modules, and because they mention looking at other servers. It wouuld 
depend on performance and scalability, so an alternate soltion would 
need to outperform and outscale Apache and FastCGI. As for the RSP 
features Maarten is adding, don't know what they are yet - it's on 
my todo list to compare the two RSPs to determine if there are features 
that the other could use.

Looks interesting, I hope you'll be able to publish here your conclusions. 
In theory, Apache+FastCGI should be faster than Cheyenne, but the 
application framework used in the FastCGI server, if not deeply optimized, 
might be a bottleneck.

btw, Dock, correct me if I'm wrong, it should be pretty easy to modify 
Cheyenne to distribute task-handlers (RSP processors) on computer 
nodes

Well, there's just a local dependency on config file to remove first 
(in my todo list) to allow remote worker process (for RSP, CGI,...). 
But you need a also a remote process manager to handle the launching 
of worker processes. Anyway, I think that using a front load balancer 
(supporting session affinity) with several servers is a simple and 
efficient solution.

What are the requirements to get a connection to a mysql database?

I have a %httpd.cfg as below   


--------------------------httpd.cfg --------------------------------

globals [  ...  worker-libs [  ...  %path/to/mysql-driver/mysql-protocol.r 
  ...  ]  ...  ]

my.virtual.host [   ....    databases [ db-name   mysql://root:[lpass-:-127-:-0-:-0-:-1]/table]	 
....   ]

----------------------------------------------------------------------


As far as I can see from the documentation and sample files, I should 
now be able to use SEND-SQL a alike on DB-NAME, but that gives nothing 
but script errors

	** Script Error : db-name has no value 
	** Where: rsp-script 
	** Near:  [print mold db-name  


I've already spent hours on this without getting a clue on what to 
do.

Of course I can connect to the database directly thru mysql-protocol, 
I just don't get it up and running with cheyenne.

Ok, I think I've might be up to something here ;-)

I've found I can use Cheyenne's own DO-SQL instead of mysql-driver's 
SEND-SQL.

I've also found out that DO-SQL expects a database WORD! instead 
of a PORT! like SEND-SQL.

Heaving learned all that, I'm now able to replace the former error 
message with that one:

#[object! [ code: 502 type: access id: cannot-open arg1: %/E/Cheyenne/ 
arg2: #[none] arg3: #[none] near: [change-dir save-path compress-output 
all [ not response/buffered? not empty? response/buffer response/flush 
response/flush/end ] ] where: #[none] ]]

Leaving me as clueless as I was before.

Ok, got it, finally. Problem was DO-SQL's signature differing from 
what I've been used too, having dealt with RT'S ODBC drivers most 
of the time. Sorry for the noise.

DO-SQL is higher level than SEND-SQL. You don't have to deal with 
ports using DO-SQL.

How did you generated the last error message? It looks like a RSP 
internal error (should have been caught at script level).

I think I was using DO-SQL with a LIT-WORD! database name and a simple 
STRING! select statement, which - hard to tell - may have had a type 
back then. Hard to tell afterwards; I'm not able to reproduce that 
particular error message now. And I've deleted the trace log once 
things started to fall into place. Putting the select statement in 
a block seemed to be what solved my problem, but I tried so many 
things that I don't recall the actual order in which I changed my 
.rsp-code.

Is there a Cheyenne release with all the new features available?

Doc asked "Third party tools can be used to tunnel SSL, like stunnel 
or nginx. About RSP, does Cheyenne's RSP miss some features required 
by Qtask?"

Maarten might be best to answer this.


BrianH wrote ""because they use PHP I'm guessing" - the promotional 
web site uses some PHP, but the main site is all REBOL."


I want to rephrase this, to help make it clear.  Qtask is written 
100% in REBOL.  We call this the "service".  The website on the other 
hand (which has nothign to do with the service), uses PHP, becuase 
there are many tools that the Webmaster wanted to use in PHP.

Doc, RSP by itself.. I use a version which does set word capturing 
(do you do that?) and allows page inclusion and context injection 
with "captured" words on the subpage. Do you do that?


Otherwise, a lot of Qtask "the application"  is Javascript on the 
UI calling API services - RSP is of little use there. The main web 
site... I would actually oppose REBOL. Why spend time there on e.g. 
a shopping cart when you can take one of the shelf and spend that 
time improving the real product (the service/application)?

Back to RSP, if you allow nested RSP and do word capturing BUT passing 
words between parten/child pages, I''d say, yes, Cheyenne's RSP is 
very good.

Word capturing => yes, all RSP running inside a webapp are captured 
in the webapp execution context, to avoid global context pollution. 
This doesn't apply to standalone RSP scripts (outside a webapp), 
but that feature could be easily added.


Page inclusion => yes, you can include RSP scripts in RSP. See http://cheyenne-server.org/docs/rsp-api.html#def-21

context injection with 

captured" words on the subpage" => I don't understand precisely what 
you describe here. In Cheyenne/RSP, subpages are captured in the 
webapp unique context, like parent pages, so there's no special treatment 
for subpages. Do you imply exporting just a selected list of words 
from the subpage script to the parent context?

Graham: no, not yet. If you have an urgent need for the new version, 
I can make a snapshot of my development version.

is rename somehow changed in cheyenne compared to regular rebol?

I can't seem to make it work normally

I can only rename in current directory .. also doesn't seem to work 
in a subdirectory of current dir