| # | User | Message | Date |
| 11149 | Dockimbel | Thanks for digging this up, I'll have a quick look on it later today. | 26-Jan 12:48 |
| 11148 | Endo | But it is not the only problem because if I replace // with / in "new" then it doesn't produce error but gives 404. rejoin [cfg/root-dir req/in/path file] exists in mod-static.r file but it works well. So there should be something wrong in req/in/path IF there is databases section in webapp. I don't know how related they are. | 26-Jan 11:31 |
| 11147 | Endo | Doc: I found where the bug is:
It is in mod-fastcgi.r file line 65:
new: rejoin [cfg/root-dir req/in/path file] cfg/root-dir: %www/testapp/ req/in/path: "/" file: %index.rsp new: %www/testapp//index.rsp | 26-Jan 11:22 |
| 11146 | Dockimbel | Thank you for the test, I'll will try to reproduce it here. | 26-Jan 10:30 |
| 11145 | Endo | Chrome shows "No data received" Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data. | 26-Jan 8:00 |
| 11144 | Endo | Doc: Same error with latest r173 version.
I just put the databases block into webap block, didn't change anything in the testapp, webapp [ databases [ cdr odbc://sa:qwe123@cdr ] virtual-root "/testapp" root-dir %www/testapp/ auth "/testapp/login.rsp" ;debug ] error is: code: 515 type: 'access id: 'invalid-path arg1: {/E/cheyenne-sources/Cheyenne/www/testapp//index.rsp} Note that the double slash in arg1. | 26-Jan 7:57 |
| 11143 | Endo | I will test tomorrow morning. | 25-Jan 21:59 |
| 11142 | Dockimbel | Can you reproduce the same issue with latest revision from sources? | 25-Jan 16:08 |
| 11141 | Endo | Oh when I moved database section from WebApp to globals section then it works! | 25-Jan 16:04 |
| 11140 | Endo | I have a problem with cheyenne-r0920-cmd.exe on Windows, when I comment database section in my http.cfg it works, when I uncomment it gives the following error in chey-pid-9036.log file: 25/1-17:58:14.625-## Error in [uniserve] : On-received call failed with error: make object! [ code: 515 type: 'access id: 'invalid-path arg1: "/E/cheyenne/www/centrex//index.rsp" arg2: none arg3: none near: [info? new [ req/in/target: form file if ext: find/last req/in/target dot [ req/in/ext: to word! ext req/handler: select service/handlers req/in/ext ] if not req/in/file [req/in/file: new] if d?: declined? req [return false] ]] where: 'throw-on-error ] ! note that there is double slash before index.rsp I don't know why. Error happens before I use any do-sql or something. Web page doesn't work at all. | 25-Jan 16:04 |
| 11139 | sqlab | maybe win-call uses a different home directory for the key file | 15-Jan 5:06 |
| 11138 | sqlab | plink is a ssh command line tool of the putty package | 15-Jan 5:04 |
| 11137 | PeterWood | The plink example didn't work for me. I got the following message: >> win-call/output "plink.exe -l user -pw password checkall@host df " str: make stri ng! 102 4 == {CreateProcess failed!: The system cannot find the file specified.} Though I got a similar message from the console: C:\Documents and Settings\Peter>plink.exe -l user -pw password checkall@host df 'plink.exe' is not recognized as an internal or external command, operable program or batch file. | 14-Jan 12:39 |
| 11136 | Dockimbel | You can use SDK v2.7.6, it has no issues with Call on Windows, AFAIR. | 13-Jan 15:38 |
| 11135 | sqlab | win-call/output "plink.exe -l user -pw password checkall@host df " str: make string! 1024 tia | 13-Jan 14:00 |
| 11134 | PeterWood | If you let me know which ones, I'll try them out on my machine .... but I won't be able to do so just now. | 13-Jan 13:40 |
| 11133 | sqlab | unfortunately not all is working. I still get back nothing or the error file for some operations, that work with call. | 13-Jan 13:30 |
| 11132 | sqlab | thanks, this seems to work better | 13-Jan 13:21 |
| 11131 | PeterWood | sqlab Re: Win-Call Have you tried using the full "command", I suspect that may be the problem you are facing: >> do %call.r Script: "Untitled" (none ) >> win-call/output "cmd.exe /c dir" str: make string! 1024 == none >> probe str { Volume in drive C has no label.^M Volume Serial Number is F4A6-6294 ^M ^M Directory of c:\Red\quick-test^M ^M 09/11/2011 18:26 <DIR> .^M 09/11/2011 18:26 <DIR> ..^M 09/11/2011 06:16 6,148 .DS_Store^M 13/10/2011 18:16 8,545 call.r^M etc. | 13-Jan 12:38 |
| 11130 | Dockimbel | As long as clients use the standard websockets protocol, they will work with Cheyenne. | 11-Jan 20:55 |
| 11129 | amacleod | Does cheyenne websockets work with socket.io (http://socket.io/ ) or some other third party client library that allows websocketes to work on mobile and non websocket browsers? | 11-Jan 18:59 |
| 11128 | Dockimbel | There is not much that can be done at HTTP level to protect against that, unless you get back to HTTP/1.0 and forbid keep-alive states. It is also worth mentioning that multithreaded servers (one client connection = one thread), will suffer much more from such attacks than event-based single threaded ones. | 7-Jan 12:06 |
| 11127 | Henrik | Maybe this is interesting: Causing a DoS by reading server responses very slowly: https://community.qualys.com/blogs/securitylabs/2012/01/05/slow-read | 7-Jan 10:13 |
| 11126 | Dockimbel | The main point of making sessions persist on disk, is to allow Cheyenne to be restarted without loosing user's sessions (and force them to log in again). | 27-Dec 22:50 |
| 11125 | Dockimbel | It can cause some problem only when you're changing Cheyenne version or when you're upgrading your app and changing the data structure format stored in sessions. You can enable or disable it using the PERSIST config keyword described here: http://cheyenne-server.org/wiki/Config/Persist | 27-Dec 22:48 |
| 11124 | Henrik | but isn't that precisely what causes the problem? | 27-Dec 21:54 |
| 11123 | Dockimbel | This file is used to save on disk sessions objects when Cheyenne is stopped. | 27-Dec 21:33 |
| 11122 | Dockimbel | Henrik: Cheyenne does delete it, but before that it loads it in memory. That's why I've said that you should manually delete it before Cheyenne is restarted, to avoid it being loaded back. | 27-Dec 21:32 |
| 11121 | Dockimbel | Janko: DO/GLOBAL is the official way, *do is just for internal use. | 27-Dec 21:31 |
| 11120 | Janko | btw: I yesterday used Ladislav's excellent!! closure with cheyenne and it didn't work. Then I found it's because of do which it uses .. It worked once I changed it to *do | 27-Dec 20:39 |
| 11119 | Henrik | "delete the .rsp-sessions file if present before starting Cheyenne" - Why does Cheyenne not do this on start? | 27-Dec 20:38 |
| 11118 | Dockimbel | (dinner time, bbl) | 27-Dec 20:26 |
| 11117 | Dockimbel | Also, you should also delete the .rsp-sessions file if present before starting Cheyenne (to avoid loading possible obsolete sessions structures in never Cheyenne version). | 27-Dec 20:26 |
| 11116 | Dockimbel | You can quickly port all older code by just adding /GLOBAL to all DO calls (especially for global libraries loaded in app-init.r). | 27-Dec 20:25 |
| 11115 | Henrik | aha | 27-Dec 20:23 |
| 11114 | Dockimbel | By default, DO binds the code to the webapp execution context, to get the native DO (with binding to global context), you need to use DO/GLOBAL. | 27-Dec 20:23 |
| 11113 | Henrik | I rewrote app-init.r for this version. | 27-Dec 20:22 |
| 11112 | Dockimbel | If you upgraded from a really older version, you might get some issues with the libraries loading from app-init.r as DO behaviour was changed in more recent versions. | 27-Dec 20:22 |
| 11111 | Henrik | getting more random hangs... | 27-Dec 20:20 |
| 11110 | Henrik | aha, so errors are buried a bit deeper than I thought. | 27-Dec 20:19 |
| 11109 | Henrik | I'm getting a number of very strange things. DO doesn't work either. | 27-Dec 20:17 |
| 11108 | Dockimbel | READ should behave the same wherever you use it, in app-init.r events or RSP scripts. | 27-Dec 20:17 |
| 11107 | Henrik | no, pure REBOL. I found now that using READ inside app-init.r causes this hang for a worker process as well. | 27-Dec 20:12 |
| 11106 | Dockimbel | Are you using a PHP engine through FastCGI? | 27-Dec 20:11 |
| 11105 | Henrik | curiously, now I have hanging worker processes, when I stop cheyenne. | 27-Dec 17:56 |
| 11104 | Henrik | oh well, installed new version, so we'll see if it happens again. | 27-Dec 17:50 |
| 11103 | Henrik | (why do I always get duped by cheyenne version numbers...) | 27-Dec 17:33 |
| 11102 | Henrik | apparently it's an older version, as I can't use the debug features. | 27-Dec 17:16 |
| 11101 | Dockimbel | I've tried a lot of different hand-crafted request to try to crash Cheyenne and reproduce your issue, but Cheyenne is keeping responding right. | 27-Dec 16:51 |
| 11100 | Dockimbel | Henrik: what revision of Cheyenne are you using? | 27-Dec 16:41 |
| 11099 | Dockimbel | Why not, I will study that option tomorrow. | 25-Dec 21:20 |
| 11098 | Henrik | perhaps we need some kind of test server set up, which we can throw garbage and flood requests at? it could be useful for testing such things. | 25-Dec 11:16 |
| 11097 | Henrik | ok, thanks. | 25-Dec 11:15 |
| 11096 | Dockimbel | I have a working session on Cheyenne planned tomorrow, I will have a look at the issue more closely. | 25-Dec 11:13 |
| 11095 | Dockimbel | Truncation: that could be caused by a bug in the HTTP access log batch writing, the log cache seems to have been desynchronized by the request. | 25-Dec 11:11 |
| 11094 | Dockimbel | My guess is that some HTTP/1.0 request with data but without Host or Content-length field might trigger this bad behaviour from Cheyenne. | 25-Dec 11:08 |
| 11093 | Henrik | (that is not a paste error) | 25-Dec 11:08 |
| 11092 | Henrik | I find it also interesting that the first line is truncated at the beginning. | 25-Dec 11:08 |
| 11091 | Dockimbel | There are some filters in HTTPd decapsulation routine in Cheyenne that should prevent invalid requests to pass, but this one seems to have passed through. | 25-Dec 11:07 |
| 11090 | Dockimbel | It also could be a regression in Cheyenne for HTTP/1.0 support, I would need to check that. The huge number of log entries suggests that Cheyenne is trying to interpret incoming data as pipelined requests, instead of just dropping it down. | 25-Dec 11:05 |
| 11089 | Henrik | Does it warrant some type of garbage filter? Obviously something like this should be ignored. | 25-Dec 11:04 |
| 11088 | Dockimbel | That could explain the "none-access.log" file, if the request doesn't have a Host field defined. | 25-Dec 11:02 |
| 11087 | Dockimbel | Hmm, intriguing...Seems that you received a request with garbage, either an attack or flooding attempt. The HTTP/1.0 suggests that the request is not coming from a web browser (all are using HTTP/1.1 now). | 25-Dec 11:02 |
| 11086 | Henrik | OK. I saw it as a REBOL process was suddenly racing at 100% CPU. Someone accessed my site, which posted an entry in the default-access.log with an HTTP 1.0 request: 74.52.168.98 - - [25/Dec/2011:10:30:29 +0100] "GET / HTTP/1.0" 200 9 Then 5 minutes later, the none-access.log appears and I'm flooded with requests until that log is 45 MB in size. The file starts like this: .168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 - 74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 - 74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 - 74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 - .... 45 MB of this | 25-Dec 10:55 |
| 11085 | Dockimbel | 1. Depends on which log file you're thinking of, I guess it's for HTTP access logs. It's composed by virtual host name followed by "-access.log". 2. It could be an internal bug or a misconfiguration issue, anyway, Cheyenne should not produce such files. | 25-Dec 10:50 |
| 11084 | Henrik | Two things: 1. what is the mechanism that determines the name of a log file? 2. would it be a bug, if I saw a log file named none-access.log? | 25-Dec 9:55 |
| 11083 | Kaj | I don't know if this handles the full spec, though | 23-Dec 23:43 |
| 11082 | Kaj | read-lines: func ["Read text lines from a file." file [file! url!] /local line ][ if all [not empty? file: read/lines file find/match line: first file "^(EF)^(BB)^(BF)" ][ remove/part line 3 ; Remove BOM ] file ] | 23-Dec 23:43 |
| 11081 | Kaj | Here's a function I use to remove BOMs I got from Windows files: | 23-Dec 23:42 |
| 11080 | Dockimbel | See "Parameters" section from Cheyenne's wiki: http://cheyenne-server.org/wiki/Rsp/Basis | 23-Dec 17:35 |
| 11079 | amacleod | I'm trying to generate an .rsp page based on a query string the way a cgi page does using 'decode-cgi system/options/cgi/query-string' but it does not seem to be working. How is this sort of thing done with .rsp? | 23-Dec 16:04 |
| 11078 | Dockimbel | Sounds like a good idea (making INCLUDE remove UTF-8 BOM, if found). | 21-Dec 18:01 |
| 11077 | Oldes | Browsers like Chrome or Firefox are fine if find a BOM inside html, but for example IE6 had a problem - at least in my case. So far I just resaved my source, but I can imagine that it will reappear in a future again (as UTF8 with BOM is default). | 21-Dec 15:52 |
| 11076 | Oldes | It's a not big issue, but I noticed, that the include function does not removes BOM from the files. Do you think it's worth to improving it or let people to maintain it manually in the files which are being included? | 21-Dec 15:49 |
| 11075 | Dockimbel | AUTH regression (error when not used in a webapp): fixed in last revision. | 17-Dec 13:44 |
| 11074 | Dockimbel | Ok, it's now supporting FF too. | 17-Dec 13:38 |
| 11073 | Dockimbel | Also, the ws-test-app test application has been fixed too and now works correctly (in Chrome at least, I should add support for FF too). | 17-Dec 13:23 |
| 11072 | Dockimbel | Handling of websockets disconnection event has been fixed in the latest revision. | 17-Dec 13:21 |
| 11071 | Dockimbel | I will be busy or offline in the next days until 14/12, I won't have time to make the changes/fixes to ws before that. | 11-Dec 22:44 |
| 11070 | Dockimbel | Re 2): I should reformulate it, you can pass serialized values only. | 11-Dec 22:43 |
| 11069 | Dockimbel | Interact with ws clients from job: it's possible only if you pass the clients list in the block. | 11-Dec 22:42 |
| 11068 | Endo | 2) in ws-test-app.r file it says do-task/on-done takes an argument that can be anything.
But when call do-task/on-done with any non-string argument I get an error, am I doing something wrong?
I tried with a port (connected ws client) and a integer, both failed: 11/12-6:17:04.1090-## Error in [mod-socket] : On-timer call failed with error: make object! [ code: 303 type: 'script id: 'expect-arg arg1: 'do-task arg2: 'data arg3: [string!] near: [do-task/on-done 5 func [client data] [ send client join "Job end: " reform [now/time tab i] ]] where: :action ] ! | 11-Dec 4:22 |
| 11067 | Endo | Doc: "You can just pass a block! value as a job to the scheduler and call your code from there, it would be cleaner than hacking in on-timer." How do I interact with "clients" connected via ws inside a "job" block? I have "clients" block in on-timer event and I able to send messages to them. Is it possible from jobs? | 11-Dec 3:15 |
| 11066 | Dockimbel | Yes, it's probably related to my last modifications in Cheyenne on AUTH handling. I will see if I can find time to fix that this weekend. | 10-Dec 9:33 |
| 11065 | Endo | When I remove AUTH line from WEBAPP section in httpd.cfg file, the browser always returns :ERR_EMPTY_RESPONSE error.
Here is my part of httpd.cfg
webapp [
virtual-root "/testapp"
root-dir %www/testapp/
; auth "/testapp/login.rsp"
;debug
] in %testapp/ I have test.html and test.rsp they both very simple files, I have app-init.r also. But I can never access those files. In Cheyenne log file I see following error: 10/12-3:11:39.3120-## Error in [uniserve] : On-received call failed with error: make object! [ code: 303 type: 'script id: 'expect-arg arg1: 'second arg2: 'series arg3: [series! pair! event! money! date! object! port! time! tuple! any-function! struct! event!] near: [either url: second pos: find] where: 'process-webapp ] ! As a work around I put auth line to a rsp file that just do session/content/login?: yes and redirect. Do you have any idea? I tested with 0920 and r164. | 10-Dec 1:15 |
| 11064 | Endo | "I tested ws.html in Cheyenne sources on my XP/Home yesterday with Chrome, it closes the connection immediately. But it works here now, on XP/Pro with Chrome." I just tested on XP/Home it works well. I think it was not the latest version I've tested yesterday. | 9-Dec 23:31 |
| 11063 | Endo | And one more thing: I think I found the reason of "Warning in [boot] : Premature exit from event loop" message in on-timer event, and fixed:
client removed AFTER the on-disconnect event, so CLIENTS are not EMPTY? while the last client disconnecting. I changed the 43. line on ws-test-app.r file from: if empty? clients [ to if 1 = length? clients [ And problem solved. | 9-Dec 12:45 |
| 11062 | Endo | One last thing: in ws.html there is a button to close the connection:
<button onClick=" alert('button closed');conn.close();"> Disconnect </button> But I never get onClose event and don't see a connection close on server logs: conn.onclose = function(evt) { alert("Conn closed"); } And "tick"s appear even if I click on Disconnect. | 9-Dec 12:36 |
| 11061 | Endo | Ok thank you. Bye! | 9-Dec 12:22 |
| 11060 | Dockimbel | Need to go, be back later. | 9-Dec 12:22 |
| 11059 | Dockimbel | You can just pass a block! value as a job to the scheduler and call your code from there, it would be cleaner than hacking in on-timer. | 9-Dec 12:21 |
| 11058 | Endo | It looks like I can use on-timer event to do my async polling and then sending the results for each client. | 9-Dec 12:19 |
| 11057 | Dockimbel | Right, it's a side-effect of on-timer, I should fix it somehow to avoid that message. | 9-Dec 12:17 |
| 11056 | Endo | I think it because of on-timer event. When I remove it from ws.-test.app.r no warning appear anymore. | 9-Dec 11:59 |
| 11055 | Endo | I'm running latest Cheyenne from its source. | 9-Dec 11:55 |
| 11054 | Endo | I got "9/12-13:54:40.187-# Warning in [boot] : Premature exit from event loop !" if I close the browser. Is it ok? | 9-Dec 11:55 |
| 11053 | Endo | I'll try again tonight. | 9-Dec 11:52 |
| 11052 | Dockimbel | Chat demo: in fact, it should work ok in all cases, because the UTF-8 encoding is done by the browser and the chat back-end just broadcast it as is to others. | 9-Dec 11:52 |
| 11051 | Endo | yep I just downloaded yesterday. But actulally the donwloaded program downloads another one, so it may be different for Home and Pro. | 9-Dec 11:51 |
| 11050 | Dockimbel | ws.html: same Chrome version on both machines? | 9-Dec 11:50 |
| 11049 | Dockimbel | Chat demo: no conversion, it's UTF-8 as long as everyone talks in english. ;-) | 9-Dec 11:49 |
| 11048 | Endo | Is it UTF-8 in your chat example? Cheyenne converts text to UTF-8?
Text mode is ok to me. By the way, I tested ws.html in Cheyenne sources on my XP/Home yesterday with Chrome, it closes the connection immediately. But it works here now, on XP/Pro with Chrome. | 9-Dec 11:42 |
| 11047 | Dockimbel | Just something to keep in mind when working on websockets: the transer mode used by Cheyenne to reply to clients is "text" mode. This mode requires UTF-8 encoding and IIRC, the browser is allowed to reject your response and close the connection if the response is wrongly encoded. | 9-Dec 11:38 |
| 11046 | Dockimbel | Your plan should work well. | 9-Dec 11:36 |
| 11045 | Dockimbel | Web socket + database query: it won't block if you transfer the query job to an RSP script. See the ws demo app: %www/ws-app/ws-test-app.r and the back-end RSP script: %www/ws.rsp | 9-Dec 11:33 |
| 11044 | Endo | My plan is, adding database to Cheyenne config, poll in an aysnc way (jobs, task-master, etc.) and send something to clients over web socket. | 9-Dec 11:31 |
| 11043 | Endo | "You could also use an async HTTP query on an RSP script instead." This might do the job. | 9-Dec 11:28 |
| 11042 | Endo | Thank you. I'll try. What I'm working on is, to poll a database table and send some changes to a client on a web socket. polling should not block Cheyenne of course. | 9-Dec 11:28 |
| 11041 | Dockimbel | You could also use an async HTTP query on an RSP script instead. | 9-Dec 11:28 |
| 11040 | Dockimbel | You might have to use a longer access path like: uniserve/shared/do-task | 9-Dec 11:27 |
| 11039 | Dockimbel | I think you can (if you know how to build a "handler" for Task-master). | 9-Dec 11:26 |
| 11038 | Endo | Can I use Task Master from jobs, if I added my module to UniServe? something like: jobs [every 5 s do [shared/do-task [...] ] ] | 9-Dec 11:13 |
| 11037 | Dockimbel | CALL is a better option I guess. | 9-Dec 10:10 |
| 11036 | Dockimbel | If you're using the encapped version, LAUNCH will just instanciate the Cheyenne binary. | 9-Dec 10:09 |
| 11035 | Endo | jobs [every 5 s do [launch %test.r]] does same. | 9-Dec 10:08 |
| 11034 | Endo | Wow something weird happened..
jobs [every 5 s do %test.r] --> creates a new cheyenne process every 5 seconds %test.r --> REBOL [] print now | 9-Dec 10:07 |
| 11033 | Endo | Ok, I'm testing LAUNCH.. | 9-Dec 10:02 |
| 11032 | Dockimbel | Yes, you can also use CALL in a function if you prefer. | 9-Dec 10:00 |
| 11031 | Dockimbel | LAUNCH %script = CALL on REBOL executable passing the script as argument. | 9-Dec 9:59 |
| 11030 | Endo | oh sorry :) use CALL in a function :) | 9-Dec 9:57 |
| 11029 | Endo | hmm, there is no CALL option? | 9-Dec 9:56 |
| 11028 | Dockimbel | To answer your question, if the type of action is file!, it should not block Cheyenne, others will block. It should be possible to make the url! action not block by using an async HTTP query instead of READ (just adding the HTTP async client for UniServe should work). | 9-Dec 9:41 |
| 11027 | Dockimbel | (I remember having issues with LAUNCH, let me know if it works for you) | 9-Dec 9:38 |
| 11026 | Dockimbel | It depends on the type of the "action" part of the job rule. Here's what does the scheduler by default (UniServe/libs/scheduler.r): url! [read action] block! [do action] file! [launch action] function! [do :action] word! [do get :action] | 9-Dec 9:37 |
| 11025 | Endo | Doc: When I use jobs section in httpd.cfg, the jobs are executed in Cheyenne or UniServe process or it uses Task Master? I mean the jobs can block Cheyenne or not? | 9-Dec 8:15 |
| 11024 | Dockimbel | You're welcome. | 29-Nov 15:10 |
| 11023 | Endo | Ok, now I got it. Thanks a lot. | 29-Nov 15:08 |
| 11022 | Dockimbel | As the (long) note explains it, it's a special API for closely integrating Cheyenne HTTP server with an existing app. | 29-Nov 15:07 |
| 11021 | Dockimbel | No, it's the embed API, see 'publish-site and 'testapp specs in %embed-demo.r | 29-Nov 15:07 |
| 11020 | Endo | I mean its included in the application but still runs in RSP engine? | 29-Nov 15:06 |
| 11019 | Endo | Is it not RSP? | 29-Nov 15:06 |
| 11018 | Endo | Oh but there a "testapp" in embed-demo.r? and its not plain HTML. | 29-Nov 15:06 |
| 11017 | Dockimbel | If you want a full-featured Cheyenne and integrate your own GUI app, you would have to make it the other way around, which is include your app in %cheyenne.r. | 29-Nov 15:05 |
| 11016 | Dockimbel | No, they are all disabled in embedded mode. From "Notes" header in %embed-demo.r: All the other modules will be disabled while mod-embed is active (current behaviour, it may change in the future). | 29-Nov 15:03 |
| 11015 | Endo | Works great. Thank you! "the embedded mode is for providing an HTTP server to an existing app, not a full-featured Cheyenne" But I can use RSP, websockets and webapps I think, right? | 29-Nov 15:00 |
| 11014 | Endo | Sure | 29-Nov 14:56 |
| 11013 | Dockimbel | update => updating | 29-Nov 14:56 |
| 11012 | Dockimbel | Do not forget to run Cheyenne once after update your files to refresh the cache.efs file. | 29-Nov 14:55 |
| 11011 | Endo | Ok, great. Let me test.. | 29-Nov 14:55 |
| 11010 | Dockimbel | I pushed a fix in the repo. | 29-Nov 14:55 |
| 11009 | Dockimbel | It was left out because I never tested encapping in embedded mode. | 29-Nov 14:54 |
| 11008 | Endo | I see, so its only for mod-embed.r not for other mods I think. | 29-Nov 14:53 |
| 11007 | Dockimbel | Ok, I can reproduce it. The module is missing from the Cheyenne package list in %cheyenne.r | 29-Nov 14:52 |
| 11006 | Endo | Here is the error: make object! [ code: 500 type: 'access id: 'cannot-open arg1: "/C/Documents and Settings/endo/mods/mod-embed.r" arg2: none arg3: none near: [do any [get-cache file file]] where: 'do-cache ] | 29-Nov 14:50 |
| 11005 | Dockimbel | Strange, all the dependent files should be encapped in the executable. Testing locally... | 29-Nov 14:49 |
| 11004 | Endo | "I don't understand what you mean by "external" there?" when I copy embed-demo.exe alone to outside cheyenne directory, it gives an error like "cannot find the file mods/mod-embed.r". So even encapped it requires that file and probably the other modules (.r) files. What I was thinking, when I use embed mode and encap the cheyenne, it already includes necessary mod files into encapped exe. | 29-Nov 14:47 |
| 11003 | Dockimbel | Btw, the embedded mode is for providing an HTTP server to an existing app, not a full-featured Cheyenne. If you want to make a GUI app in View for just a few simple interaction with Cheyenne, you can just #include your View code in %cheyenne.r. | 29-Nov 14:23 |
| 11002 | Dockimbel | "websocket test server application": you already have it, just run cheyenne.exe and start writing your websocket app. | 29-Nov 14:21 |
| 11001 | Dockimbel | I don't understand what you mean by "external" there? | 29-Nov 14:19 |
| 11000 | Endo | So, mod-embed.r should be external anyway? | 29-Nov 13:22 |
| 10999 | Endo | I did not yet test but with this way we can easily write a websocket test server application. | 29-Nov 13:22 |
| 10998 | Dockimbel | You don't need to include any Cheyenne own files, %cheyenne.r takes care about all the required dependencies when encapping. | 29-Nov 13:21 |
| 10997 | Endo | I think it is also possible to include mod-embed.r file. Currently embed-demo.exe requires mods/mod-embed.r file (probably the other mods as well) | 29-Nov 13:20 |
| 10996 | Endo | Fantastic! Thanks a lot Doc! Now I can make show to my manager for our next project :) | 29-Nov 13:14 |
| 10995 | Dockimbel | At line 147, you should read "Comment the following line..." instead of "Comment this line..." (fixed in r162). | 29-Nov 11:11 |
| 10994 | Dockimbel | I have added a few lines to embed-demo.r to show you how to prepare it for encapping with Cheyenne running in embedded mode: http://code.google.com/p/cheyenne-server/source/detail?r=161 | 29-Nov 11:10 |
| 10993 | Endo | I tested on WinXP Pro SP3. Same error as in r151. | 29-Nov 8:24 |
| 10992 | Endo | encapped embed-demo.exe application gives the following error: ** Script Error: select expected series argument of type: series object port ** Where: get-cache ** Near: select cache file | 29-Nov 8:23 |
| 10991 | Endo | Thank you. I'll test tomorrow morning. | 29-Nov 0:49 |
| 10990 | Dockimbel | Endo: I have pushed a few fixes for regressions in embedded mode support. I'm now looking into the possibility of encapping it that mode. | 28-Nov 22:09 |
| 10989 | Dockimbel | Thanks for testing. | 28-Nov 21:42 |
| 10988 | Kaj | Chat demo works with Firefox 8.0.1 on Linux | 28-Nov 21:06 |
| 10987 | Dockimbel | The first parameter (a URL) is mandatory and should point to the resource where login happens (it's a pass-thru, every other URL will be redirected or will return a custom HTTP code, if specified). | 28-Nov 18:49 |
| 10986 | Dockimbel | Janko: I have extended AUTH to be able to return an HTTP code in revision 157: FEAT: AUTH config keyword can now take an optional second parameter (HTTP code 4xx or 5xx) that will be returned to client instead of a redirection to the login URL. | 28-Nov 18:48 |
| 10985 | Dockimbel | You would need at least one of these browser to use the new websockets support: Chrome 14, FF 8 or IE 10. | 28-Nov 16:59 |
| 10984 | Dockimbel | Websocket support updated to hybi-10 revision. Websocket chat demo also upgraded: http://demo.cheyenne-server.org:8080/chat.html | 28-Nov 16:58 |
| 10983 | Dockimbel | Some were very interested by a simple, small and easily deployed web server that could run PHP code efficiently. | 28-Nov 14:34 |
| 10982 | Dockimbel | There was about 25 people in the audience, a lot moved to other, more PHP-focused, conferences at the same time. | 28-Nov 14:33 |
| 10981 | Dockimbel | Btw, a RSS feed is available for the Cheyenne blog. | 28-Nov 14:32 |
| 10980 | Dockimbel | See: http://cheyenne-server.org/blog.rsp?view=29 | 28-Nov 14:30 |
| 10979 | Pekr | Did the presentation to php audience already happen? What was the recpetion of Cheyenne? | 28-Nov 14:23 |
| 10978 | Dockimbel | Should be in a an hour or two. | 28-Nov 14:15 |
| 10977 | Dockimbel | I'll do a quick test on that just after finishing the websocket implementation. | 28-Nov 14:14 |
| 10976 | Endo | about encap: I'll try to find the problem and if it's not difficult I try to fix it as well. I wanted to ask before spending time on it. Thank you. Doc: if you already done / test it please let me know. I'm planning to use it in a production. | 28-Nov 14:13 |
| 10975 | Ryan | I ended up replacing the read with one that determines if its encrypted by the filename. Decrypts rsp or includes. Works nice. Thanks for helping get started on that. | 25-Nov 23:48 |
| 10974 | Dockimbel | In handlers/RSP.r | 25-Nov 21:56 |
| 10973 | Ryan | Where do I find engine? | 25-Nov 21:54 |
| 10972 | Ryan | I see it now. | 25-Nov 21:46 |
| 10971 | Dockimbel | INCLUDE is just the user API front-end. | 25-Nov 21:44 |
| 10970 | Dockimbel | Loading and compilation of RSP scripts are done in ENGINE object, not by INCLUDE. | 25-Nov 21:44 |
| 10969 | Dockimbel | You could add a property to ENGINE object for controlling how files are loaded, and set/unset it depending on INCLUDE refinement. | 25-Nov 21:43 |
| 10968 | Ryan | patch it to do what? | 25-Nov 21:43 |
| 10967 | Dockimbel | You would also need to patch the engine/add-file method where the RSP scripts are really loaded. | 25-Nov 21:41 |
| 10966 | Ryan | got it. thanks! | 25-Nov 21:40 |
| 10965 | Dockimbel | I think that the cleanest way would be then to extend the existing INCLUDE function in RSP.r by adding a refinement (/with or /options) and use it to pass additional custom data to the INCLUDE function (like a 'decrypt word, followed by a key). | 25-Nov 21:39 |
| 10964 | Ryan | Sounds easy enough. | 25-Nov 21:36 |
| 10963 | Dockimbel | I guess yo would need to modify the RSP engine for that. The easiest way would probably be to create a custom 'include function able to decrypt your files. | 25-Nov 21:34 |
| 10962 | Ryan | or just includes is fine | 25-Nov 21:32 |
| 10961 | Dockimbel | You mean you need to encrypt RSP files? | 25-Nov 21:32 |
| 10960 | Ryan | One thing I need to do is add encrypted script files. What do you think would be the most logical method, modifying source or making my own interpreter? | 25-Nov 21:31 |
| 10959 | Dockimbel | I'm glad it's useful to someone. :-) | 25-Nov 21:31 |
| 10958 | Ryan | Excellent work on Cheyenne, Doc! The structure is mostly excellent for what I am doing. | 25-Nov 21:28 |
| 10957 | Dockimbel | Not recently, but yes. | 25-Nov 21:19 |
| 10956 | BrianH | Don't know if this has been discussed before, but have you looked into SPDY? | 25-Nov 17:45 |
| 10955 | Dockimbel | I am not sure I have ever tested encapping Cheyenne in embedded mode. I will test that this weekend, I will anyway spend some hours to complete the new websockets implementation. | 25-Nov 17:42 |
| 10954 | Endo | Did anyone tried Cheyenne in embeded mode? | 25-Nov 14:08 |
| 10953 | Endo | when I encap embed-demo.r, embed-demo.exe gives this error:
** Script Error: select expected series argument of type: series object port
** Where: get-cache
** Near: select cache file Do I need to do something else? I uncommented "embed" in httpd.cfg. | 25-Nov 13:03 |
| 10952 | Dockimbel | Thanks, I'll publish my slides tomorrow afternoon on Cheyenne's site. | 24-Nov 23:17 |
| 10951 | Kaj | Good luck with your presentation | 24-Nov 20:17 |
| 10950 | Dockimbel | I have pushed a preliminary implementation of the latest websocket RFC to Cheyenne SVN repo. It works only for text messages of size < 126 bytes. I will get back to it in the next day and complete it. | 24-Nov 16:15 |
| 10949 | Dockimbel | In the end, the burden will fall on my shoulders if I want fixes and updates to be done in time (as usual). If someone makes such lib (just 3 lines of C, btw), maintains it (means provide binaries for target platforms), I can add an optional loader in Cheyenne to use it when present. As for myself, I prefer to switch to Red asap. | 24-Nov 14:38 |
| 10948 | Geomol | Make the C lib open source and let people, who want that functionality, maintain the lib. It shouldn't necessarily be your job. | 24-Nov 14:31 |
| 10947 | Dockimbel | "to that" = "for that" | 24-Nov 14:29 |
| 10946 | Dockimbel | Yes, but in Cheyenne context, having to maintain a cross-platform C lib to that would be really annoying. It would be the end of Cheyenne as a one-file server. Also, it wouldn't run on Core anymore. | 24-Nov 14:28 |
| 10945 | Geomol | Can it be solved by calling a routine from a dynamic linked library? | 24-Nov 14:25 |
| 10944 | Dockimbel | Bad news for websocket support in REBOL: the new RFC requires that client encodes data sent to server using a basic XOR encryption algorithm: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-4.3 This is a bad news for us, because it requires to process all bytes received, one by one to decode the message. REBOL is very slow at processing big data in loops, so the overhead can be very significant for data frames of a few dozen KB and more. It could affect Cheyenne global performances drastically. However, it could have been worse, this encryption scheme is not required for data sent by server. So, as long as clients are sending small messages (up to a few KB), the overhead should be low. Fortunately, the usual client messages are queries to obtain data, so usually small. But if you have to move big amouts of data (like XML documents) back and forth through websockets, Cheyenne won't be able to cop with the load and it will most probably be a show-stopper. | 24-Nov 13:50 |
| 10943 | Dockimbel | Small stuff: probably, but if you ever need to scale up, better start right from the beginning. | 23-Nov 17:02 |
| 10942 | Pekr | Those locks last only a fraction of time imo. Shouldn't it be good for small stuff? | 23-Nov 17:01 |
| 10941 | Pekr | Sounds good, no? | 23-Nov 17:00 |
| 10940 | Dockimbel | "When any process wants to write, it must lock the entire database file for the duration of its update" "However, client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time. This is possible in a client/server database because there is always a single well-controlled server process available to coordinate access. If your application has a need for a lot of concurrency, then you should consider using a client/server database." | 23-Nov 17:00 |
| 10939 | Dockimbel | http://www.sqlite.org/faq.html#q5 "Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however." | 23-Nov 16:58 |
| 10938 | Dockimbel | Reliable and efficient file locking is hard to achieve, I agree with that. That's why I went for a syslog-like solution for Cheyenne. | 23-Nov 16:49 |
| 10937 | Kaj | It makes heavy requirements on the file locking of the operating system for that, and it does have a document section that explains how operating systems are buggy and badly documented, so that doesn't exactly instill confidence | 23-Nov 16:48 |
| 10936 | Kaj | Judging by the documentation it should be able to do it, but I admit I usually mistrust such things | 23-Nov 16:45 |
| 10935 | Dockimbel | SQLite use to have issues handling concurrent writes (data corruption could happen), I don't know if recent versions improved that or not. | 23-Nov 16:40 |
| 10934 | Kaj | I thought SQLite supports concurrent access. Isn't that so? | 23-Nov 15:47 |
| 10933 | Kaj | That's very welcome | 23-Nov 15:43 |
| 10932 | Dockimbel | The newer websocket RFC is much better written and more exhaustive than the previous versions. The protocol has also nicely improved fixing the remaining security issues. | 23-Nov 15:39 |
| 10931 | Dockimbel | Btw, I am currently working on making Cheyenne websocket support conform to the latest RFC specification. The current Cheyenne support is obsolete and won't work anymore with latest browsers. | 23-Nov 15:38 |
| 10930 | Kaj | 0MQ is already heavily async, and you can make the request/response pattern not wait | 23-Nov 15:08 |
| 10929 | Dockimbel | The probably best option would be for Cheyenne to spawn a new process that would handle all the log files serialization (both for Cheyenne internal use and for web apps). The code for that is already bundled in Cheyenne main process, so it would not be a big work to extract it and spawn a new process. (but would require at least a couple of days, including testing). | 23-Nov 14:46 |
| 10928 | Dockimbel | It could be possible to extend debug object to handle an /info refinement that would log to an %info.log file, but that would put some burden on Cheyenne main process when in production. I thought about writing an OS logging service wrapper, but never found the time for that. I usually do all my writings from webapps into databases that are able to handle concurrent accesses reliably (so, not sqlite). | 23-Nov 14:42 |
| 10927 | Janko | Endo, thanks for the code. I will need something similar for sqlite. I just got a first db is locked error yesterday with it at UsrJoy. What I'm trying to log is side-info (like usage info) so I don't want to inpact the speed of response by having aditional disk write in the request-response process (it has to be async). Doc: I used debug functions for various info logging too now (and I do diff on trace in cron and send myself email if there is any difference), but I am trying to log more things and I would like to leave trace.log for errors only. I was interested if the existing functionality that serializes debug to trace.log could be used to log to some other file. like info.log . That would complicate the app-code the least.. otherwise I was thinking of what Kaj proposed, to have some queue to send data over via tcp to and it will write it to disk in intervals. That would bring another dependancy into app-code.. something like redis could automatically work like this I think. | 23-Nov 14:25 |
| 10926 | Kaj | You could also make your own syslog server with 0MQ and send log messages to it from RSP scripts. That will offload the writing to a different process and 0MQ will take care of serialisation | 23-Nov 13:50 |
| 10925 | Dockimbel | You can use debug/* logging functions, but they will only log in %trace.log file. Writing directly to a log file from RSP script is unsafe (unless you take great care about concurrent accesses). So, if you want to have custom logs from RSP scripts, you should use the OS syslog service for a really realiable solution. The debug/* log functions use their own solution for serializing disk writes, they are passing data to Cheyenne main process that does the writings to disk. | 23-Nov 12:35 |
| 10924 | Endo | I think its ok to use append if its not a heavy-loaded web site.
I did this to prevent possible file access problem if it happens same time in very rare cases: unless 'ok = loop 3 [ if not error? try [ save voter-file append voters session/content/username ] [ break/return 'ok ] wait 0:0:0.1 ] [ response/redirect "error.rsp?code=error-on-voting" ] | 23-Nov 12:29 |
| 10923 | Janko | I want to log certain events from the webapp. What would be the most efficient way to do this (by this I mean one that would have least impact on server responsivenes). I would like to use something silimar to debug/probe debug/print .. Is it possible to have use the existing loging functionality to log custom stuff to custom log? (or is this just normal file append)? | 23-Nov 10:32 |
| 10922 | Dockimbel | Too bad I thought it was a hardware issue and I sent a reboot from the control panel, just a few seconds before realizing that the server plan has expired. The server was running since 670 days uninterrupted. | 20-Nov 22:38 |
| 10921 | Dockimbel | Ok, server is up again, issue solved. | 20-Nov 22:36 |
| 10920 | Dockimbel | My main server is down since a few hours due to a non-technical issue. This affects all the following web sites:
- cheyenne-server.org
- curecode.org
- part of red-lang.org The problem should be solved in an hour. This server is still owned by my former company, Softinnov, who forgot to do the renewal in time. | 20-Nov 21:56 |
| 10919 | Janko | great | 19-Nov 17:56 |
| 10918 | Dockimbel | I think that Gabriele could also have some good inputs on the best practices to support, as he's doing a lot of AJAX programming. | 19-Nov 17:55 |
| 10917 | Janko | Ok, great.. I will get by when time comes | 19-Nov 17:52 |
| 10916 | Dockimbel | I'm looking forward to it! | 19-Nov 17:51 |
| 10915 | Janko | I will have a lot more experiences about this in few months because I am just working on this stuff regarding the API and export. I used aditional get param so user can select what format she wants. But I was educated by this guy that I should look at Accept headers, which I ignored happily ..:) .. same about statuses which I didn't use. Now I am getting home at this, so we can talk in a while and determine the most systematic and clean way for this. And such that will make the REST purists happy | 19-Nov 17:50 |
| 10914 | Dockimbel | Precisely. :-) | 19-Nov 17:48 |
| 10913 | Janko | but yes, the question is what is the best way to determine the JSON mode (or XML or CSV or ...) | 19-Nov 17:48 |
| 10912 | Janko | hm.. same would be then for error, again when in JSON mode .. instead of html explanation you should return 500 | 19-Nov 17:47 |
| 10911 | Janko | well .. you decide .. for me it's not a problem, really .. and I am also starting to think about HTTP codes now so I don't have the clearest view yet | 19-Nov 17:46 |
| 10910 | Janko | I quickly mocked up how ajax code would look if you made it return 401 onChange2: function(rq, pars) { this.assureLANG(); if (rq.readyState == 4) { if (rq.status == 401) { alert(LANG.err.session_exp); window.location = window.location.href.replace(/#.*/g, "")+""; } else if (rq.status = 200) { success(r.responseText); } else if (rq.status == 403) { validation(r.responseText); } else { this.onError(); } } }, | 19-Nov 17:45 |
| 10909 | Dockimbel | So, I will spend at least a day on it. | 19-Nov 17:42 |
| 10908 | Dockimbel | I also need to review PHP support as I will make a Cheyenne presentation next week at a big PHP meeting here. | 19-Nov 17:42 |
| 10907 | Dockimbel | Well, the biggest task is getting websockets up again, modifying AUTH should really be a matter of a few lines of code. | 19-Nov 17:41 |
| 10906 | Janko | Cheyenne was serving me well for all this time and this is no real issue .. just a notice for future maybe | 19-Nov 17:41 |
| 10905 | Janko | -- You really don't have to change it now .. you can add this any time later when it maybe clears out even better .. I don't want to keep you from RED | 19-Nov 17:40 |
| 10904 | Janko | This was my old code because ot it (I check for </html> and </form> to see if I signed out) . Now I am making it status for validation for example it will be status 403, etc .. onChange2: function(rq, pars) { this.assureLANG(); if (rq.readyState == 4) { if (rq.responseText) { if ( rq.responseText.indexOf('</html>') > 0 ) { if ( rq.responseText.indexOf('</form>') > 0 ) { alert(LANG.err.session_exp); window.location = window.location.href.replace(/#.*/g, "")+""; } else { alert(LANG.err.ajax_err); } } else { c(r.responseText); } } else { this.onError(); } } }, | 19-Nov 17:38 |
| 10903 | Dockimbel | If you think there's a more general solution to this use-case, let me know. | 19-Nov 17:38 |
| 10902 | Dockimbel | If you need it, I should be able to add it easily. | 19-Nov 17:37 |
| 10901 | Dockimbel | In the next days, I will spend a day or two on Cheyenne, to fix a few pending issues (like the broken websocket compatibility after latest RFC changes). | 19-Nov 17:37 |
| 10900 | Janko | I can detect all other codes with XHR yes, except 3* .. so if server returned 401 without content JS would then make what is appropriate. | 19-Nov 17:36 |
| 10899 | Janko | as I say, it's not a practical problem for me. :) Just a suggestion.. I am making external API and I got some developers that are very sensitive to propper HTTP so I am rewriting my api to all those codes.. But this is not a problem for that, since API doesn't use cheyenne's sessions.. just while I am rewriting my ajax code I thought of it. | 19-Nov 17:35 |
| 10898 | Dockimbel | In such case, Cheyenne would just return an HTTP code with no content and would let the client handle the redirection to login form (or whatever other action is suited). | 19-Nov 17:35 |
| 10897 | Dockimbel | So, if you could specify, for example: AUTH <http code> (instead of providing an URL), would it work with XHR? | 19-Nov 17:34 |
| 10896 | Janko | but XMLHttpRequest isn't able to return any of 30* codes .. in case of 30* it automatically redirects and returns the result with 200 | 19-Nov 17:32 |
| 10895 | Dockimbel | So, if you redirect to an AJAX-generating script, it should be ok (depending how your application is handling login). | 19-Nov 17:32 |
| 10894 | Janko | yes, that is true.. you make a redirection | 19-Nov 17:31 |
| 10893 | Janko | yes, I agree it's not so straightforward .. you could only redirect when there is accept: "*html*" .. | 19-Nov 17:31 |
| 10892 | Dockimbel | So, there's nothing to parse there for Cheyenne. | 19-Nov 17:31 |
| 10891 | Dockimbel | Cheyenne doesn't return HTML when a session times out, it only returns a 301 (or 302, I don't remember) to the URL you've specified in the config file after AUTH. | 19-Nov 17:30 |
| 10890 | Dockimbel | What if the request has other mime-types in addition to that one? :-) | 19-Nov 17:29 |
| 10889 | Janko | or like you check now it here is any html returned in debug more, if not you don't render the debug bar | 19-Nov 17:29 |
| 10888 | Janko | yes, that question crossed my mind :) ... maybe this should hold only if request has: "Accept: application/json" | 19-Nov 17:28 |
| 10887 | Dockimbel | It should be possible to either extend the AUTH config option to specify an "ajax" mode or to add a new AUTH-AJAX config option. | 19-Nov 17:28 |
| 10886 | Dockimbel | How can Cheyenne know that's an "ajax request"? | 19-Nov 17:26 |
| 10885 | Janko | Just one question, nothing urgent. Would it be possible or smart if cheyenne would return http 401 to ajax request when the session times out? Now it basically return 200 and login form html (so I have to test for presence of </form>) instead of usuall JSON. | 19-Nov 17:24 |
| 10884 | Kaj | That was probably when G-WAN had been in development for a year, so in any case it would be incomparable to the current Linux version, which is not mature yet, either | 19-Nov 0:52 |
| 10883 | Kaj | It seems to have been developed on Server 2003. Maybe it doesn't work on newer Windows versions. It was discontinued in September 2009 | 19-Nov 0:50 |
| 10882 | sqlab | Yes, but I just used the examples as they are explained in the manual for the windows version. | 18-Nov 19:54 |
| 10881 | Kaj | Sqlab, G-WAN for Windows is discontinued, a year ago or so | 18-Nov 14:56 |
| 10880 | Kaj | Well, there you have it: the other web servers don't | 18-Nov 14:54 |
| 10879 | Dockimbel | That's the only rational way to use threads IMO too. | 18-Nov 14:54 |
| 10878 | Kaj | Specifically, it uses a pool of one thread per core for an event based architecture | 18-Nov 14:53 |
| 10877 | Dockimbel | That's what I plan to do too for Red. | 18-Nov 14:53 |
| 10876 | Kaj | The main point is that G-WAN basically uses the BeOS/Syllable architecture: one process with worker threads | 18-Nov 14:52 |
| 10875 | Dockimbel | Yes, especially when you're serving only to localhost (like in the gwan benchmark). | 18-Nov 14:52 |
| 10874 | Kaj | Cheyenne/Red doesn't have to be closed source and write scripts in C | 18-Nov 14:51 |
| 10873 | Kaj | Copying chunks of memory is what you do when serving static files, isn't it? | 18-Nov 14:51 |
| 10872 | sqlab | I tried gwan on Windows with a logs directory as described in the manual. It crashed. Also the listen options on startup did not work. | 18-Nov 11:31 |
| 10871 | Dockimbel | Also, this is closed source software. | 18-Nov 9:58 |
| 10870 | Dockimbel | The main benchmark graph is basically testing how fast each server is able to copy chunks of memory. ;-) http://gwan.ch/benchmark | 18-Nov 9:57 |
| 10869 | Dockimbel | I am not sure that web developers are ready to jump to C for writing their server-side scripts (especially with error reports that include CPU registers content :-) ). | 18-Nov 9:47 |
| 10868 | Kaj | http://gwan.ch/ | 18-Nov 0:47 |
| 10867 | Kaj | Here's inspiration for Cheyenne/Red: | 18-Nov 0:47 |
| 10866 | Janko | nenad designed cheyenne very well, that's why it's so fast! | 12-Nov 15:21 |
| 10865 | Janko | I just added few lines to parse where it compiles in it's multilang stuff - which is btw very good since it does it only once and then holds cached version same as for languages :) | 12-Nov 15:21 |
| 10864 | Janko | btw: I added few lines to cheyenne so it solves my only major hurdle with javascript (I need to write a lot of javascript for my apps, and I use sort of functional style). shorter syntax for anonymouse functions + returns. Nothing big or complex... f{ a, b | .... } ==> function ( a, b ) { ..... } r{ a, b | a + b } ==> function ( a, b ) { return a + b } not sure if it's usefull to anyone else or has place in real cheyenne, since it's just more of a hack (and not standard in any way). If anyone need it, let me know) | 12-Nov 15:18 |
| 10863 | Dockimbel | Done. | 11-Nov 19:56 |
| 10862 | Dockimbel | Main PHP process froze. I'm restarting it. | 11-Nov 19:55 |
| 10861 | Ryan | Cheyenne-server.org is taking a long while to serve the wiki pages. | 11-Nov 19:53 |
| 10860 | Dockimbel | Not standalone, you would need a SSL front-end for that, like stunnel or nginx. | 6-Nov 21:18 |
| 10859 | Ryan | Can Cheyenne do SSL? | 6-Nov 21:08 |
| 10858 | GrahamC | More correctly Nenad is the best ... | 20-Oct 3:37 |
| 10857 | GrahamC | Glad it works ... | 20-Oct 3:36 |
| 10856 | amacleod | Graham! You are the best...thanks again! I had to use echo mode on the client (and i'm not really sure what that means) but it works! | 19-Oct 20:47 |
| 10855 | GrahamC | This works for me response/buffer: copy data response/set-header 'Content-type "application/json" | 19-Oct 19:18 |
| 10854 | amacleod | Thanks for the response Gabriele, but I just can't get this to work.
If i'm using an rsp page to send back the request:
I've got this:
<%
data: {
"one": "Singular sensation",
"two": "Beady little eyes",
"three": "Little birds pitch by my doorstep"
}
response/set-header 'Content-Type "application/json"
print rejoin ["myfunc" "({" data "})"]
%> Does not work... response in web page includes the function name which does not look like json data typically served back | 19-Oct 16:56 |
| 10853 | Gabriele | ie. if the function is called "myFunction", just return "myFunction({myData: 1, ...})" | 19-Oct 9:53 |
| 10852 | Gabriele | just return the Javascript call, like the PHP does above. | 19-Oct 9:52 |
| 10851 | amacleod | The javascript is looking for the data in a callback...how do I wrap the data in a callback using rebol and cheyenne? | 18-Oct 13:56 |
| 10850 | Andreas | (Which some people call JSONP.) | 18-Oct 13:44 |