World: r3wp

As an archive for images collected from remote cameras. (I didn't 
write the system). The system has been live for a few years. It currently 
runs under Xitami and I'm trying to help move it to a more modern 
web server. We are hoping to move to Cheyenne.


After the system has been migrated, we would then have the possibility 
to convert it, or parts of it,  to a Web App.

PeterWood: I've fixed the missing setenv mapping for Mac OS X in 
revision 108. Here are the binaries for you to test:
http://cheyenne-server.org/tmp/cheyenne-r108-pro-osx.gz
http://cheyenne-server.org/tmp/cheyenne-r108-cmd-osx.gz

You can also test it using the Perl CGI test scripts from the source 
archive in %www/perl (just change the shebang line to your local 
Perl interpreter path).

Btw, Cheyenne resets all CGI ENV variables after each CGI request 
for security concerns, so don't be surprise to not be able to see 
them from shell.

Many thanks, Doc. I'll test it straight away.

It's working fine, thanks - I can confirm that I can  access the 
env variables from a Ruby CGI.

Good!

Cool Cheyenne on OSX... I will give it a try on our new server.

SVN revision 110:

FEAT: default REBOL CGI scripts are now run as normal CGI.

FEAT: new config keyword: fast-rebol-cgi. Forces running REBOL CGI 
scripts in FastCGI mode.

FIX: (Windows) CGI handler rewritten to fix environment variables 
passing.

FIX: CGI 'set-env mapping code refactored, setup errors are now properly 
logged.
FIX: CGI scripts errors are now logged in %trace.log file.

Windows binaries are available for testing:
http://cheyenne-server.org/tmp/cheyenne-r110-pro.zip
http://cheyenne-server.org/tmp/cheyenne-r110-cmd.zip

New binaries for revision 114: http://cheyenne-server.org/blog.rsp?view=24

what was the difference between pro and cmd versions? Sorry if it 
was asked for several times before.

- pro: REBOL/Pro kernel
- cmd: REBOL/Command kernel

no functionality difference, right?

No, Cheyenne just relies on /Library and /Shell components which 
are present in both kernels.

Yes, command kernel allows you access to odbc database sources

Does cheyenne support callbacks

From where to where?

from a client app (phone app) to my server with my data base.  like 
a json call in js

using jo js framework; 

joScript(url + "&callback=Commuter.dataSource.setData");

So the server, assuming it supports a callback, sends back something 
like this, which gets executed immediately:

Commuter.dataSource.setData({ ... JSON data ...});

Maybe i'm confuesed. Is the callback a function of the web server 
or is it just how I setup my cgi script?

do i just format my data result to look like: 
Commuter.dataSource.setData({ ... JSON data ...});
and then 'print' it for the client to catch (read)?

I think so.

Also you may need to set up correct mime type. The best way is to 
use wireshark to see how it looks elsewhere.

But basicaly I guess that your framework is just using JS to get 
some data from server.

So it must be pretty easy to make it in Cheyenne.. so the final answer 
is: yes:)

I don't think that should be called a callback. The most defining 
nature of callbacks is that they are asynchronous, and that just 
doesn't fit into the browser/web server model

I suspect they would call it a callback because some JavaScript is 
transferred to be executed on the other side, but that's just exchanging 
program code, not asynchronicity

So the answer is indeed that this is nothing more than a normal request 
yielding a response, where the response happens to be JSON or maybe 
even full JavaScript. This depends entirely on your own server and 
client programs, not on the intermediating web server

The code in my Try REBOL site supports this, although it isn't even 
used that way

If you view this page https://fd.cloud-ehr.net/drugreactions.rsp?rxcuilist=855348541713 541713 849339 108911


Does your browser complain that it doesn't understand what to do 
with the rsp page?

I have this which I thought should be enough

response/buffer: to-json ResObj
response/set-header 'Content-type "application/json"

cheyenne for R3 exist ?

cheyenne for R3 exist ?

I think not. R3 has different port model. First the Uniserve engine 
would have to be ported. Then I am not sure, if Cheyenne uses DLL 
interface or not, but DLL interface is not present in R3 too, we've 
got Extension interface instead. And IIRC, one of main reasons why 
Doc did not port Cheyenne to R3 was - lack of multitasking/threading. 
So - unless RT brings tasking on-board, no Cheyenne for R3.

Graham: Chrome shows the JSON output while FF offers to download 
it. It's better to use a READ and a JSON decoder from the console 
to display JSON strings or a plugin like Firebug rather that rely 
on the browser.

Cheyenne on R3: R3 lacks /Shell and /Library components that Cheyenne 
requires, and R3 is still far from being stable (both in design and 
implementation). Extension is also far from being a /Library drop-in 
replacement, I don't want to have to write and maintain per-platform 
C code, that defeats the purpose of using a (supposedly) cross-platform 
tool and it's, IMHO, a big regression from R2. Moreover, once concurrency 
support at low-level will be ready, a big part of Cheyenne would 
need a re-design and rewrite, so I prefer to wait for that for a 
real added value of a R3 port.

Doc, I've noticed also that Firefox seems to prioritize the extension 
over the content-type header.

My Firefox 3.5 wants to save the file. Isn't that a normal reaction 
for a bare json file?

Browsers saving a received content with a application/* mime type 
looks logical to me (unless requested from a JS XHR object).

What I mean is that FF appears to value the RSP extension higher 
than the content-type header.

in some instances

I don't think that can be concluded from this case alone

I have another page which sends application/pdf and it downloads 
the rsp page instead

Or was it application/xfdf ...

If it downloads the RSP, that would be a problem in the Cheyenne 
configuration, because it is always supposed to execute an RSP

Are you sure it's Cheyenne what is giving you the rsp page?

What else?

it downloads the rsp page instead
 Do you mean that you get the RSP source or RSP output?

RSP output