World: r3wp

as long as the config GUI is only a tool over the files, and it doesn't 
overwrite the files automatically, I won't complain  :-)

Well, you'll have an option for turning it off, if you really prefer 
to type instead of clicking. ;-)

the format can become more stuctured too, if it makes it easier to 
load back in... but please don't loose the files themselves.

hehe  ;-)

Both approaches can live together. I want the config file to keep 
the same current format even if overwritten by the UI. Most users 
won't even care about the config file anymore once the UI will be 
available.

In fact, I even thought about making a lynx-compliant admin UI for 
text-only users. ;-)

as a point of fact, it is very possible that some modules (like remark) 
will require stuff to be setup which is hard to simulate through 
a gui.  managing a system of nested parameters and list is very complex 
to handle programatically.

Right, that's something Cheyenne's config file also doesn't handle 
(yet).

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?