World: r3wp

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

I'm not aware of any impact on RENAME in RSP scripts. Does your code 
work in console?

I thin I can .. I will test it more serriously and report you if 
there will be any issue

I've set up a public SVN repository for the development version of 
Cheyenne, so if anyone needs the latest patches or improvements, 
it doesn't have to wait for the next release. Access info at : http://code.google.com/p/cheyenne-server/source/checkout

Direct SVN checkout : 


svn checkout http://cheyenne-server.googlecode.com/svn/trunk/cheyenne-server-read-only

wow, cool

now that I know for dtach I can run cheyenne from source too

Did you tried the following way?

> rebol -qws cheyenne.r &

I didn't try to run cheyenne this way yet.. I needed to explore these 
options .. also the & for some mine server that was running actor 
net. I am using dtach for that and I also have one running console 
for cheyenne now

Good news about the svn

Doc, correct, but your approach works just as well for me. I explicitly 
force word passing because the web context is created in the RSP 
engine for the parent page.

So, RSP is good enough, except we are more API oriented with a Javascript 
front end :-)

Well, I've found RSP script pretty handy for web services too, generating 
dynamically javascript code or XML for AJAX requests.

XML I can see, but JSON is so close to REBOL.

I don't use much JSON, I generate the JS code directly server-side 
(using RSP) and just Eval( ) on client side.

I use cheyenne which generates mostly JSON for one project, haven't 
seen any problems

Does the trunk have the version that allows different webapps to 
access the same DB virtual name but different connections?

Yes it has, just look in the changelog file : http://cheyenne-server.googlecode.com/svn/trunk/Cheyenne/changelog.txt

thanks

Thanks Dock, much appreciated 8)

side note: if you have:
persist [sessions]

in your httpd.cfg file, stop the server and delete the %.rsp-sessions 
file before upgrading to the latest svn version

What's the relationship between vhosts and webapps?

ie. can I have webapps inside a vhost?

vhosts are just containers, so you can have one or more webapps in 
a vhost.

Thanks.

Do vhosts work with stunnel ?  ie. I can redirect incomming https 
to different vhosts?

I've just started testing the latest cheyenne out of SVN.   No matter 
what port I run it on, it always says it is runing on port 80 when 
you hover over the system tray.

I encapped cheyenne.r and now my cheyenne server just terminates 
without any entries in the crash log :(

doesn't look like you can get a verbose trace by default with the 
encapped version