World: r3wp

doc, not really.  Thing is I have different computers with different 
OS / HW / Install environments.

but the systmems they are running are the same but under different 
paths or using different ports, domains, and stuff like that.  


since all of this is done via shell, its very tedious to xfer,  manage 
& edit the data properly for a few apps.  I can easily have a single 
configuration file which just stores values, but let all the apps 
use those values in the same setups.

maybe we could add support for the get-word datatype (:word) in the 
config dialect ?  the values of those words would be substituted 
when they are encountered.  this way I could just add a keyword (or 
load it directly in the cheyenne script) which loads external data 
files and use the values in the config files.

How about this scenario.. an on-message comes in, the code then does 
a 'read on an external server.. but the server takes 30 secs to respond.. 
does that blocK?


READ is a blocking operation, so it should not be used in Cheyenne 
main process (where ws apps run). Two possible solutions :


1) Use async HTTP with callbacks (I've proposed to include in Cheyenne 
the one I'm using currently for other products).

2) Send the READ job to a worker process using DO-TASK (but it will 
block it for 30secs, so not a very scalable solution).

I would use 1).

A request comes in from the client 

IBM".. the ws-script then checks a remote server continuously pushing 
a new IBM stock quote update, second by second forever?" 

That's the typical case where you would use set-timer / on-timer.

Would you put a timer in the do-task/on-done func?


Not sure what you want to achieve precisely there. In your "READ 
quotes from remote server and send them every sec" scenario, I wouldn't 
use do-task, but async HTTP (much more efficient and scalable). I 
think I definitely need to add a few async schemes and make an example 
app.

Max: " the values of those words would be substituted when they are 
encountered."


I don't get where and how precisely this is supposed to happen (at 
Cheyenne boot time in %cheyenne.r like a preprocessor or at services 
install time in %misc/conf-parser.r as a dialect feature, and what 
could be substituted and what not, etc...). This does raise a lot 
of design questions and roughly looking, doesn't seem very different 
from what I was proposing. It seems that you'ld like the preprocessing 
occurs inside Cheyenne while I was more in favour of an external 
preprocessor script as I'm not sure how often users will need such 
feature.

Ok, thanks..

Doc, will your async-call function work with ws apps?

Requires /Library component! (needs /Pro, /Command or /SDK

this has changed, no?

what are the odds of getting an async handler that supports ssl?

2) Send the READ job to a worker process using DO-TASK (but it will 
block it for 30secs, so not a very scalable solution).

Tried this.. it's not very ws:// "broadcast" friendly

I was thinking that it could be added within the dialect... I might 
look how to add it myself and I could give you an example... maybe 
not now cause I have a lot of things on my plate, but the next time 
I go deep into cheyenne's guts (next time I work on mod-remark).

I should have my new site online within a week or two, using cheyenne 
on a linode server.  I did some of the design work this week, now 
I have to build the site around it.

I suppose having non-blocking async http and ssl, coupled with timers 
could make for a nice distributed system via ws:// . Could have clusters 
of Cheyenne :)

Async-call: yes, but not suitable for scalable server because it 
is doing intermittent busy looping to wait for incoming data from 
the child process. Once again, multithreading would have solved that 
issue.

Requires /Library component! (needs /Pro, /Command or /SDK
 : right, Core has /Library since a while.

Tried this.. it's not very ws:// 

broadcast" friendly" : I don't see why it wouldn't be? You send the 
READ job using DO-TASK and broacast the result from the ON-DONE handler.

Max: adding support for get-word! for the most common config keywords 
should be easy, just patch the config words definition in mod-static.r 
(and in other mods if required). But as you can see in mod-static 
defintions, the processing part for each keyword may not work with 
a get-word!. For example, 'root-dir expects a file! and will check 
for the trailing slash.

ahh.. i didn't use the ON-DONE handler.. just broadcast from the 
do-task part of do-task/on-handler

Why are think like Javascript not prefixed with a tilda?

sorry wrong group.

err.. scratch my last remark

what can be done is to substitute the value directly in the data 
by using change on the series and then moving one step back.  then 
the nnormal parsing will occur and the loaded value's datatype would 
be used normally  :-)

something like: [here: set value get-word! (change here get value) 
:here]

I have a weird delay happneing with the tts chat demo.. there's a 
pause of exaclty 30 seconds before the broadcast? I see no reason 
for this?

do any of the rebol loops have 30 second time-outs?? very strange

Anyway, I've restructured the echo demo.. should be much more responsive 
now

If anyone cares to try.. 

http://shinyrockets.com/echo.html

(Requires Chrome beta..  http://www.google.com/chrome/eula.html?extra=devchannel
(windows)

4.0.302.2 dev

works great :-)

If you want to see the debug tools in Chrome, hit CTRL-SHIFT-i

hehe looks like they hired the firebug coder to build the debug tools 
in chrome ;-)

yeah.. i still occasionaly use Firebug.. but rarely

Terry: echo is much faster now (1-2s delay only). 


For the 30s pause, that might be caused by a network timeout on a 
sync port action. 
>> system/schemes/default/timeout
== 30

yeah, I need an async https port.. still getting overlapping tts 
broadcasts when two or more people submit at thesame time.

It's like people trying to talk over one another, using the exact 
same voice :)

The delay is quite a bit less now - not too bad. I noticed that the 
last word (or part of one) seems to get cut off? Are you guys seeing 
the same?

yeah last word often gets cut on shorter strings .. need to get xml 
via https:// POST working for a solution.

It seems Rebol is causing the problem with the last word getting 
cut off..  I use a read/binary - write/binary of an .ogg file and 
the last bit is cut somehow?

Does it work outside of Cheyenne?

the read/write is fine.. I think it might be Cheyenne's dishing up 
of .ogg files.. ?

couldn't try it ..your server was offline

hmm.. maybe Chrome

Cheyenne has nothing against .ogg files. Are you removing ogg files 
once sent?

If Cheyenne would refuse .ogg files, then it would belong to Belief 
Systems :-)

ok.. did some tests.. it's Chrome.

Try this with FF and Chrome

http://shinyrockets.com/delme.html

(running on Apache)

although i did add the ogg to Cheyenne mime-types

http://code.google.com/p/chromium/issues/detail?id=33139