World: r3wp

In the config file is worker-libs contained within globals or should 
it be preceding globals. Trying to get mysql working.

If you're referring to the httpd.cfg file, I don't have any references 
to mysql except for those referring to actual databases. What I did 
to test mysql was use the rebol mysql driver (in a normal rebol shell) 
outside of the Cheyenne environment to make sure it worked. Hope 
that helps.

Jim: 'worker-libs have to be declared inside 'globals section of 
config file.

I usually load mysql driver from a local Cheyenne libs/ sub-folder 
:

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

Thanks Doc, I did get it running with some simple selects and updates 
now I just need to learn how to format the returned data. This is 
good stuff. By the way I am using the do-sql method and works great.

Doc, I wonder if that is my problem. I don't have worker-libs my 
httpd.cfg file.

James: it's not mandatory, you can load mysql driver from 'on-application-start 
event for example (but you'll need to do that for all your webapps). 
It's just simplier to declare it in config file once for all.

Got it.

I want to move DevBase (R3 Chat) to Cheyenne, but I must admit that 
I am a newbie with Cheyenne.


Currently the code runs as a process, and we tunnel packets thru 
HTTP via Apache.


However, I could run it as a persistent process in Cheyenne, or via 
some method that would simply put the http input and output into 
a socket.

Anyone here know how this is done?

(BTW, I'm doing this to move DevBase to the new Linnode server... 
to offload it to a faster location.)

Is this why chat is down now?

I've not shut it down yet. But, I've been having difficulty connecting 
to that server all day.  It's probably under 10 feet of snow.

If it's running as a single process .. that won't scale very well 
will it?

Wonder how much slower it would be if you ran it as rsp scripts

It scales very well... as long as it has a web server sitting in 
front of it.

as a cheyenne app it probably would run faster

The web server does the serializing and I/O buffering.

If you ran it as rsp, it wouldn't be serialized

Basically, it does not matter where the proc lives, as long as I 
can "redirect" I/O to it from the web server, which does all the 
TCP buffering.

where's the server code ?

Basically, what I want is this in raw binary I/O:

   print send-to-proc tcp-port input

I can write a CGI to do that, but it will be slower because it requires 
an extra CALL from cheyenne.

rsp doesn't use an extra call

it uses one of the existing rebol processes to deal with it

Does rsp run in binary port mode?

It must do if it accepts binary uploads

Ok, so via RSP, I can use request/posted to get the input cotent. 
 That's good.

So, I guess a short RSP should do what I need.

if you want to let users login, then you need to track a session 
cookie

And then you can run everything as a Cheyenne webapp

This is for R3 Chat, not web.  Session management is already there. 
I'm simply using a port 80 tunnel.

webapp just gives you session management with authentication, doesn't 
mean it is web

Ok... got a one line RSP that works for this:


>> to-string second load write http://host4.altme.com/echo.rsp"testing"
== "testing"

>> r: second load read/custom http://host4.altme.com/echo.rsp[ POST 
"testing" ]
connecting to: host4.altme.com
== testing

Got it!

>> to-string write http://host4.altme.com/echo.rsp"testing"
== "data: testing^/^/"

me too

The "magic" RSP line is:
<% insert tail response/buffer request/posted %>

so, now, need to throw some binary at it....

>> write http://host4.altme.com/echo.rsp#{0209103040508898af}
== #{0209103040508898AF0A0A}

Good to go.

Ok... basically got it working, but it's very slow due to hitting 
a timeout on each packet.

Why is it timing out?

And is this a http timeout or a cheyenne timeout?

The core of the problem is that SET-MODES port [close: false] is 
not supported in 2.7.  Without it, we cannot close half of the duplex 
socket.

In other words, there is no socket shutdown() function.

so the client times out ...

The server's input request packet times out.

Ok, no problem... will add content-length field. Shouldn't take much 
time.

So, R3 Chat server has been moved to Dallas TX running in Cheyenne 
on a cloud.

Not logging in though

working for me.