World: r3wp

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

I tested on WinXP Pro SP3. Same error as in r151.

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

At line 147, you should read "Comment the following line..." instead 
of "Comment this line..." (fixed in r162).

Fantastic! Thanks a lot Doc! Now I can make show to my manager for 
our next project :)

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)

You don't need to include any Cheyenne own files, %cheyenne.r takes 
care about all the required dependencies when encapping.

I did not yet test but with this way we can easily write a websocket 
test server application.

So, mod-embed.r should be external anyway?

I don't understand what you mean by "external" there?

websocket test server application

: you already have it, just run cheyenne.exe and start writing your 
websocket app.

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.