World: r3wp

Linux binaries r134 should be available in an hour at: http://cheyenne-server.org/download.shtml

Cool, thanks!

I still need to add some documentation to the wiki for .r file handling 
in RSP context and to mention the new cgi-conf script (from onetom).

what does Database C drivers: MySQL 3,Oracle 8 ... mean, btw?
it doesnt work with mysql 5 and ora 10?

Those drivers are built in REBOL/Command. It depends if Mysql 5 and 
Oracle 10 servers are compatible with older drivers. I can only answer 
for Mysql, and the answer is no.

so what's the point supplying those builds, only the https support?

or why not if u can anyway?

Not everybody run on Mysql 5 and Oracle 10, so it can be useful to 
some users. Also it's all or nothing, I cannot chose which native 
feature I want to include or not.

The ODBC driver and the SSL support are worth it.

makes sense, thx for the explanation. it just looks a bit lame to 
talk about mysql3 in 2011, isn't it?

I should maybe remove that mention from the download page...I agree 
that it looks a bit odd now.

I've upgraded Cheyenne to the latest binary, r135

It recognises the fast-rebol-cgi keyword in the globals now, but 
it doesn't seem to do anything. It seems to try to execute REBOL 
code as real CGI. It tries to use the shebang line and has permission 
problems with CGI files that it didn't have before

Thanks for the report, I will test it locally later today.

having issues starting the cheyenne server from win. it doesn't find 
the system libs.


 I had a fix for the same issue in some other code I did... I'll try 
 to see if this cures the bug in cheyenne .

What do you mean by "system libs"? kernel32.dll?

it turns out it was a different problem... he was running core.  
 but the proper way of loading libs (and I've had to do it to make 
it work on 64 bit systems)

system-libs-root: rejoin [to-rebol-file get-env "systemroot" %"/system32/" 
 ]

kernel32: load/library join system-libs-root  %kernel32.dll
user32:   load/library join system-libs-root  %user32.dll
advapi32: load/library join system-libs-root  %advapi32.dll
shell32:  load/library join system-libs-root  %shell32.dll
iphlpapi: load/library join system-libs-root  %iphlpapi.dll

I was using the simple setup you are using and it woudn't work in 
all people's windows system... the above does work in all windows 
machines.

I never tested it on 64-bit Windows, but I find it a bit odd that 
Windows can't find the system library by itself. It is supposed to 
search automatically in all default system folders.

Also, IIRC, that is the first time someone mentions such issue, and 
I am pretty sure that several peoples here already tried it on 64-bit 
Windows.

yeah, it should but it doesn't it seems  ...  the code resulted from 
feedback when I shared the windows-chrono.r lib on rebol.org and 
a user reported failing lib loading.

Confirmed, I'm running cheyenne latest .exe on Win7 64bit w/o any 
problems, .dlls just load fine.

The "system" folder is searched in all cases: http://msdn.microsoft.com/en-us/library/ms682586, 
there is no way that a call to LoadLibrary( ) (== load/library) could 
miss kernel32.dll or other system DLL that Cheyenne relies on (unless 
the user system is seriously corrupted).

Max, where's this web services plugin?

I'm at the client right now, doing last minute changes for his own 
uses.

I'll be putting a demo server on-line probably later tonight.

as well as all sources and docs as a .zip which simply appens to 
the cheyenne folders.

so you running as a local service?

the default setup is set for localhost, but it can run online, just 
set it up in one of the vhosts you are serving.

I didn't try running cheyenne as a windows service though, if that 
is what you meant.

No, I was asking the former .. if it's being used primarily as localhost

yes, right now, while testing, but there is no difference internally 
wrt using it on localhost or via vhost.

the module handler is pretty fast, considering, we are using external 
code and user hooks to setup the process.

calling this url on my meagre 1.5core2 duo
	http://localhost:81/echo.xml?value=tadam

returns this xml


<result status="success" method="echo" time-delta="0:00:00.000723302" 
phase="format-response">
    <echo value="tadam"/>
</result>

time delta is precise-timed using cpu frequency counters.

Seems very short time for an echo

Maxim: the path notation works on file! valued variables too:

>> f: join to-rebol-file get-env "HOME" %/system32
== %/Users/onetom/system32

>> f/some32.dll
== %/Users/onetom/system32/some32.dll

that's true, I always forget :-)

wrt api server speed  adding up all the required cheyenne server 
handling and tcp xfer we get:


>> s: chrono-time    read http://localhost:81/echo.xml?value=tadam 
     difference chrono-time s
connecting to: localhost
== 0:00:00.010442948

how do I prevent the printing of "connecting to: localhost" when 
I read urls?
ex: 
>> read http://localhost:81/   
connecting to: localhost
== 0:00:00.010442948

sorry... question was meant for network group

is there a way for worker threads to change the req others than the 
content, in order to tell the mod that it should switch mime types?

I guess this is the only real way to pass messages back to the cheyenne 
server:
within the mod...

task-done: func [req][
	load/all req/out/content
]

Right, if you need to pass more than just the raw data to send back 
to the client, you need to build a custom data structure from your 
handler that you would decode in the mod receiving it.

did anyone used single signon (kerberos) w cheyenne?

doc, in req/out   I have   both a value called   mime:   and   mime-type: 
   it seems that within mod phases, we are supposed to set   mime: 
   to a lit-path   ....


why is this so?  wouldn't it be simpler to have just one and set 
it as a string directly, to be used in the header construction after?

i.e, doesn't mime-type:  suffice?

There is no 'mime-type in the request object, only 'mime?? Maybe 
you were thinking about the 'set-mime-type callback?


Lit-path: for historical reason, I wanted to be able to manage content-types 
using mime classes (text/*, image/*,application/*, ...), but I didn't 
use it so far.

oh... looked at it again... my bad... I'm returning mime-type: in 
my response and the probe was really confusingly showing it as if 
the mime-type: was in the same object as the req object.

for those who might be using dividers and don't look at all the groups, 
I posted the release of mod-web-api in the announce group, yesterday.