World: r3wp

James: Latest Cheyenne binary for windows : http://cheyenne-server.org/tmp/cheyenne-rev66.exe

Do you think the curecode bugs would then magically be fixed?

 Do you really think that this is my intent by having it open sourced? 
 It's open source because its the logical way to distribute such applications 
 nowadays, offering to any user full insight and control over the 
 product.

but if you read this page:

http://www.rebol.com/rebol3/architecture.html


giving the user full "control" over the product is not the intent 
with R3. If you want "control", use one of the many variants of Python 
or Ruby. I quote "control", because at the end of the day, "control" 
will remove one of REBOL's greatest strengths in that there are no 
official derivatives of the language, that the user will just have 
to wrestle with.


Insight is another issue, which can be noble enough for educational 
purposes, and for that, the core would likely make a good study.

Open sourcing R3 core wouldn't help anything

 -- that severely underestimates the skillset available in this community

Yes, I'd estimate that a lot of bugs reported would then have patches 
available now

Wow, wrong group.

Totally :)

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?