r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

Dockimbel
9-Dec-2011
[11027x2]
(I remember having issues with LAUNCH, let me know if it works for 
you)
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).
Endo
9-Dec-2011
[11029x2]
hmm, there is no CALL option?
oh sorry :) use CALL in a function :)
Dockimbel
9-Dec-2011
[11031x2]
LAUNCH %script = CALL on REBOL executable passing the script as argument.
Yes, you can also use CALL in a function if you prefer.
Endo
9-Dec-2011
[11033x3]
Ok, I'm testing LAUNCH..
Wow something weird happened.. 

jobs [every 5 s do %test.r] --> creates a new cheyenne process every 
5 seconds

%test.r --> REBOL [] print now
jobs [every 5 s do [launch %test.r]]
does same.
Dockimbel
9-Dec-2011
[11036x2]
If you're using the encapped version, LAUNCH will just instanciate 
the Cheyenne binary.
CALL is a better option I guess.
Endo
9-Dec-2011
[11038]
Can I use Task Master from jobs, if I added my module to UniServe?
something like:
jobs [every 5 s do [shared/do-task [...] ] ]
Dockimbel
9-Dec-2011
[11039x3]
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.
Endo
9-Dec-2011
[11042x3]
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.
Dockimbel
9-Dec-2011
[11045x3]
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.
Endo
9-Dec-2011
[11048]
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.
Dockimbel
9-Dec-2011
[11049x2]
Chat demo: no conversion, it's UTF-8 as long as everyone talks in 
english. ;-)
ws.html: same Chrome version on both machines?
Endo
9-Dec-2011
[11051]
yep I just downloaded yesterday.

But actulally the donwloaded program downloads another one, so it 
may be different for Home and Pro.
Dockimbel
9-Dec-2011
[11052]
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.
Endo
9-Dec-2011
[11053x4]
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.
Dockimbel
9-Dec-2011
[11057]
Right, it's a side-effect of on-timer, I should fix it somehow to 
avoid that message.
Endo
9-Dec-2011
[11058]
It looks like I can use on-timer event to do my async polling and 
then sending the results for each client.
Dockimbel
9-Dec-2011
[11059x2]
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.
Endo
9-Dec-2011
[11061x5]
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.
Dockimbel
10-Dec-2011
[11066]
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.
Endo
10-Dec-2011
[11067x2]
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
] !
Dockimbel
11-Dec-2011
[11069x3]
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.
Dockimbel
17-Dec-2011
[11072x4]
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.
Oldes
21-Dec-2011
[11076]
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?