World: r3wp

RENAME, on same file system. if you don't want to care, call "mv"

And move-file won't be fast all the time. e.g. if you're moving the 
file to another drive.

here is from the change-log:

RSP: new method 'store added to Request object. It simplifies uploaded 
files

   management by abstracting file's location (memory or disk). Example:

			request/store request/content/file %attached/
			

   will save the uploaded file passed as "file" query parameter in %attached/ 
   folder
	  using the original name (!!watch out for security issues!!).
	  
	  		request/store request/content/file %attached/my-file.bin
	  		

   will save the uploaded file with a forced name (original name needs 
   to be saved
	  separatedly if needed).

latest svn use rename instead of call "mv xx"..

code is in cheyenne/handlers/RSP.r

I'm currently reworking the response/store function. I'm considering 
dropping in-memory uploaded files mode, it was supposed to help processing 
uploaded data files (think CSV files for example) avoiding the disk 
write/read part, but it just adds complexity for a marginal gain. 
If anyone found that mode useful, please say so now.

I think the in-memory mode is not much needed for me. I was a little 
bit suprised why some files are in memory and other on disk. And 
usualy you would like to store the original file (for example the 
csv) before processing anyway.

With the request/store - does it means that the rsp processing starts 
before the upload is finished = stops where the /store is called 
waiting on upload finish?

well, I have routines to check for in memory or on disk receipt ..

And do you save the in memory content?

Usually do save it to disc ...

When uploading a file, the RSP script is called when the upload is 
completed.

speaking of uploads.. try it with this.. http://www.plupload.com/example_queuewidget.php

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 %>