World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
Dockimbel 9-Nov-2010 [9213] | Tracing it. That's odd: the general binding is done in misc/macosx.r. I don't see why cgi.r should do it double The CGI.r code is run in a separate process, it inherits OS bindings from misc/macosx.r only when encapped. It should have worked using the /cmd binary, I need to look into it and patch the CGI code to not bind twice when encapped. |
PeterWood 9-Nov-2010 [9214x3] | Just to confirm that I am running the /cmd binary. |
.. and am running CGI scripts not fastCGI scripts - I even checked that the env variables are getting set by running a trivial Ruby cgi,. | |
.. and they are not getting set. | |
Dockimbel 9-Nov-2010 [9217] | and am running CGI scripts not fastCGI scripts REBOL scripts are run directly by CGI.r, the CGI interface is emulated, set-env is not used for REBOL scripts. I'll do some testing with non-REBOL scripts on OS X today. |
PeterWood 9-Nov-2010 [9218x5] | Doc - I am trying to test running REBOL/Services CGI under Cheyenne. It looks as though REBOL/Services will not run as fastcgi so we are running as an ordinary cgi. |
The actual system will run under Windows but we've encountered a strange problem. I'm trying to do some testing on my Mac to try to isolate the problem. | |
The problem is that the response back to the client is getting corrupted but we haven't isolated where yet. | |
This is a debug print of a correct response: req/result [ done [reply seq 1 service "Generic REBOL Service" commands 1 time 0:00] ok [date 9-Nov-2010/2:16:33-7:00] ] | |
Quite often we get something like: req/result [?done [reply seq 1 service "Generic REBOL Servidb" commands 1 time 0:00] ok [date 9-Nov-2010/2:16:35-7:00] ] | |
Dockimbel 9-Nov-2010 [9223] | What are you using REBOL/Services for? |
PeterWood 9-Nov-2010 [9224] | 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. |
Dockimbel 10-Nov-2010 [9225x3] | 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. | |
PeterWood 10-Nov-2010 [9228x2] | 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. | |
Dockimbel 10-Nov-2010 [9230] | Good! |
Robert 10-Nov-2010 [9231] | Cool Cheyenne on OSX... I will give it a try on our new server. |
Dockimbel 17-Nov-2010 [9232] | 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 |
Dockimbel 19-Nov-2010 [9233] | New binaries for revision 114: http://cheyenne-server.org/blog.rsp?view=24 |
Endo 24-Nov-2010 [9234] | what was the difference between pro and cmd versions? Sorry if it was asked for several times before. |
Dockimbel 24-Nov-2010 [9235] | - pro: REBOL/Pro kernel - cmd: REBOL/Command kernel |
Endo 24-Nov-2010 [9236] | no functionality difference, right? |
Dockimbel 24-Nov-2010 [9237] | No, Cheyenne just relies on /Library and /Shell components which are present in both kernels. |
GrahamC 24-Nov-2010 [9238] | Yes, command kernel allows you access to odbc database sources |
amacleod 25-Nov-2010 [9239] | Does cheyenne support callbacks |
Kaj 25-Nov-2010 [9240] | From where to where? |
amacleod 25-Nov-2010 [9241x5] | 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)? | |
Oldes 26-Nov-2010 [9246x4] | 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:) | |
Kaj 26-Nov-2010 [9250x4] | 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 | |
GrahamC 1-Dec-2010 [9254x2] | 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" | |
Claude 1-Dec-2010 [9256x2] | cheyenne for R3 exist ? |
cheyenne for R3 exist ? | |
Pekr 1-Dec-2010 [9258] | 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. |
Dockimbel 1-Dec-2010 [9259x2] | 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. | |
GrahamC 1-Dec-2010 [9261] | Doc, I've noticed also that Firefox seems to prioritize the extension over the content-type header. |
Kaj 1-Dec-2010 [9262] | My Firefox 3.5 wants to save the file. Isn't that a normal reaction for a bare json file? |
older newer | first last |