World: r3wp

Back to advocacy, then :)

Switch to Advocacy or Licensing.

Henrik: continuing topic in Advocacy

I used the variable 'captcha in my registration.rsp, and that has 
overwritten the variable in my web apps :(

which uses the Cheyenne captcha ...

I should have added a protect 'capcha to avoid such issues.

I've wrapped all my code into a context ...

so no more issues ...

Is there anyone using Cheyenne with SQLite?

Never tried. You might have issues with concurrent accesses.

What about making SQLite as an Uniserve service?

All SQLite accesses would block the server, so it would be OK by 
making a standalone Uniserve+sqlite combo. Such SQLite  frontend 
exists already (don't remember if it was made in C, Python or Ruby).

Oldes: I am using it

In www.cebelca.biz each user has it's own sqlite database

I did use it once with cheyenne but had issues, not sure it was concurrency 
or driver version and/or osx version or sqlite version

I suspect if you make a uniserve service then requests are serialized

What happens if I call a process that does not return .... eg.  a 
rebol server via a batch command .. is the helper process blocked?

If you use call it using the /WAIT refinement, you'll block the helper 
process.

use call it => call it

thanks

Thanks Doc. I appreciate that executable.

This is odd .. I tried calling my batch file using a full path, and 
it did not work.  The only thing that did work was to cd to the directory 
and then call it without the path.

LFReD ported to websockets using the TTS from the demo. Opens up 
a whole new world.

I already have a paid gig for it as well :)

It's a company supplying the Olympics, and needs audio feedback as 
it scans product out of the warehouse... "Im sorry, but that pallet 
does not contain all of the necessary product to fulfill this order. 
Please add 3 more units of spam, and have a nice day"

:)

That's very good Terry!

Does Cheyenne's url-encode function correctly encode something like 
this "==" ?

I tried the url-encode from the repository ... and it does nothing.
It should do this
>> url-encode "=="
== "%3D%3D"

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.