World: r3wp

The code in the Cheyenne cgi.r handler will only create the library 
binding for Windows and Linux.

I could patch cgi.r if I was certain that I should use /usr/lib/libc.dylib 
in place of /lib/libc.so.6 or .5

So do you have the Library component on OS X? That's what's needed 
to do it

Yes it has the Library component:

Is OS X detection missing in Cheyenne, then?

This is the code is cgi.r that creates the binding;

any [
				all [
					system/version/4 = 3			; Windows
					libc: load/library %kernel32.dll
					_setenv: make routine! [
						name	[string!]
						value	[string!]
						return: [integer!]
					] libc "SetEnvironmentVariableA"
					body: [_setenv name value]
				]
				all [								; UNIX
					any [
						exists? libc: %/lib/libc.so.6
						exists? libc: %/lib/libc.so.5
					]
					libc: load/library libc
					_setenv: make routine! [
						name	[string!]
						value	[string!]
						return: [integer!]
					] libc "setenv"
					body: [_setenv name value 1]
				]
			]

As you can see it is missing OS x

Detection is in misc/os.r. It's very simple, so I think it should 
work

It's not the detection that's missing, it's the binding to the correctly 
named lib that is missing.

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

You can copy the relevant code from macosx.r to cgi.r

Thanks, Kaj  - I'll try to check that out later.

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.

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.

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.

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]
]

What are you using REBOL/Services for?

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