World: r3wp

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.

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.

Strange, all the dependent files should be encapped in the executable. 
Testing locally...

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
]

Ok, I can reproduce it. The module is missing from the Cheyenne package 
list in %cheyenne.r

I see, so its only for mod-embed.r not for other mods I think.

It was left out because I never tested encapping in embedded mode.

I pushed a fix in the repo.

Ok, great. Let me test..

Do not forget to run Cheyenne once after update your files to refresh 
the cache.efs file.

update => updating

Sure

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?

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

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.