World: r3wp

http://www.google.com/codesearch/p?hl=en#8-MruDvODLg/trunk/UniServe/libs/html.r&q=url-encodepackage:http://cheyenne-server%5C.googlecode%5C.com&sa=N&cd=2&ct=rc&d=2

>> url-encode/all "=="
== "%3D%3D"

the switch /all includes also url-reserved: charset "&/:;=?@" as 
you can see in the code you have linked here:)

ahh ....

so what's the point of not doing /all as default?

Because those characters are url syntax, and encoding them would 
break the syntax.

Particularly = and & would break url-encoded name/value pairs.

I encode each part of the url and then rejoin

I guess his url-encode encodes the whole url ....

Under those circumstances it's safe to se url-encode/all.

I do this as well with my own url-encode function as Graham as I 
consider it as more safe

ech.. too many "as" ... must go to sleep :)

What's the correct way how to deal with uploaded files? I mean... 
if I for example upload a very large file, then I must move it to 
correct location after upload is finished. What is the best way how 
to move a large file in the Cheyenne context? What about a possibility 
to set the custom %incoming/ location before download starts so no 
need for move will be required and we can just rename the file?

I think that under Windows for fast file movement I can use:
set 'MoveFile make routine! [
   		"Moves file using OS"
        lpExistingFileName  [string!]
        lpNewFileName [string!]
   ] kernel32.dll "MoveFileA"
But what about under Linux? Just a simple call?

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