World: r3wp

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.

Oh but there a "testapp" in embed-demo.r? and its not plain HTML.

Is it not RSP?

I mean its included in the application but still runs in RSP engine?

No, it's the embed API, see 'publish-site and 'testapp specs in %embed-demo.r

As the (long) note explains it, it's a special API for closely integrating 
Cheyenne HTTP server with an existing app.

Ok, now I got it. Thanks a lot.

You're welcome.

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?

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]

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

hmm, there is no CALL option?

oh sorry :) use CALL in a function :)

LAUNCH %script = CALL on REBOL executable passing the script as argument.

Yes, you can also use CALL in a function if you prefer.

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.

If you're using the encapped version, LAUNCH will just instanciate 
the Cheyenne binary.

CALL is a better option I guess.

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.