World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
onetom 24-Apr-2011 [10071x2] | so what's the point supplying those builds, only the https support? |
or why not if u can anyway? | |
Dockimbel 24-Apr-2011 [10073x2] | 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. | |
onetom 24-Apr-2011 [10075] | makes sense, thx for the explanation. it just looks a bit lame to talk about mysql3 in 2011, isn't it? |
Dockimbel 24-Apr-2011 [10076] | I should maybe remove that mention from the download page...I agree that it looks a bit odd now. |
Kaj 24-Apr-2011 [10077x2] | 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 | |
Dockimbel 25-Apr-2011 [10079] | Thanks for the report, I will test it locally later today. |
Maxim 27-Apr-2011 [10080] | 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 . |
Dockimbel 27-Apr-2011 [10081] | What do you mean by "system libs"? kernel32.dll? |
Maxim 27-Apr-2011 [10082x3] | 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. | |
Dockimbel 27-Apr-2011 [10085x2] | 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. | |
Maxim 27-Apr-2011 [10087] | 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. |
ChristianE 27-Apr-2011 [10088] | Confirmed, I'm running cheyenne latest .exe on Win7 64bit w/o any problems, .dlls just load fine. |
Dockimbel 27-Apr-2011 [10089] | 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). |
GrahamC 27-Apr-2011 [10090] | Max, where's this web services plugin? |
Maxim 27-Apr-2011 [10091x3] | 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. | |
GrahamC 27-Apr-2011 [10094] | so you running as a local service? |
Maxim 27-Apr-2011 [10095x2] | 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. | |
GrahamC 27-Apr-2011 [10097] | No, I was asking the former .. if it's being used primarily as localhost |
Maxim 27-Apr-2011 [10098x3] | 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. | |
GrahamC 27-Apr-2011 [10101] | Seems very short time for an echo |
onetom 27-Apr-2011 [10102] | 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 |
Maxim 27-Apr-2011 [10103x6] | 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 ] | |
Dockimbel 28-Apr-2011 [10109] | 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. |
onetom 28-Apr-2011 [10110] | did anyone used single signon (kerberos) w cheyenne? |
Maxim 28-Apr-2011 [10111x2] | 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? | |
Dockimbel 28-Apr-2011 [10113] | 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. |
Maxim 28-Apr-2011 [10114] | 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. |
Maxim 29-Apr-2011 [10115] | 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. |
Maxim 30-Apr-2011 [10116] | Graham, did you try the webservice mod? |
GrahamC 1-May-2011 [10117] | I am wondering if I can use this to control various applications I have running. They currently run with GUIs, but I think I should use a web service module to control them so that I can run them all GUI less. |
Maxim 1-May-2011 [10118] | well, you can still have a gui, but all it needs to do is build URLs and confirm the results :-) |
GrahamC 2-May-2011 [10119] | the web service would communicate internally via a tcp port ... so that should work. |
onetom 2-May-2011 [10120] | 2/5-19:59:12.259281-## Error in [conf-parser] : Error in conf file at: ! does this look familiar to anyone? there is no ! in the httpd.cfg of course |
older newer | first last |