World: r3wp

Can I use Task Master from jobs, if I added my module to UniServe?
something like:
jobs [every 5 s do [shared/do-task [...] ] ]

I think you can (if you know how to build a "handler" for Task-master).

You might have to use a longer access path like: uniserve/shared/do-task

You could also use an async HTTP query on an RSP script instead.

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.

You could also use an async HTTP query on an RSP script instead.
 This might do the job.

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.

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

Your plan should work well.

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.

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.

Chat demo: no conversion, it's UTF-8 as long as everyone talks in 
english. ;-)

ws.html: same Chrome version on both machines?

yep I just downloaded yesterday.

But actulally the donwloaded program downloads another one, so it 
may be different for Home and Pro.

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.

I'll try again tonight.

I got "9/12-13:54:40.187-# Warning in [boot] : Premature exit from 
event loop !" if I close the browser. Is it ok?

I'm running latest Cheyenne from its source.

I think it because of on-timer event. When I remove it from ws.-test.app.r 
no warning appear anymore.

Right, it's a side-effect of on-timer, I should fix it somehow to 
avoid that message.

It looks like I can use on-timer event to do my async polling and 
then sending the results for each client.

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.

Need to go, be back later.

Ok thank you. Bye!

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.

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.

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.

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.

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.

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?

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

Interact with ws clients from job: it's possible only if you pass 
the clients list in the block.

Re 2): I should reformulate it, you can pass serialized values only.

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.

Handling of websockets disconnection event has been fixed in the 
latest revision.

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).

Ok, it's now supporting FF too.

AUTH regression (error when not used in a webapp): fixed in last 
revision.

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?

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).

Sounds like a good idea (making INCLUDE remove UTF-8 BOM, if found).

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?

See "Parameters" section from Cheyenne's wiki: http://cheyenne-server.org/wiki/Rsp/Basis

Here's a function I use to remove BOMs I got from Windows files:

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
]

I don't know if this handles the full spec, though

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?

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.

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

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).