World: r3wp

Yeah :)

There is a faster method, but saving it for other stuff.

Terry, is the demo not really working right now? I don't seem to 
get anything back.

Should be working.. it's alpha though

AdrianS: are you using Chrome 4?

yes - I did manage to get a response once

after quite a long time

but it doesn't seem to work anymore

wow, I got a response after more than 4 minutes - is that the lag 
mentioned above?

I tried to do the same text again, but no reponse this time

I think i need to move some stuff into a timer.. loops in ws-apps 
seem to block, and create all sorts of problems.

My goal isn't to have TTS conversations, but the ability to push 
TTS whenever i want.

I can imagine things like log analysis, and having a "intruder alert" 
announcement.. stuff like that.

(closing the demo now)

Doc: Dress socks funded if you address Windows Integrated Authorization 
for Cheyenne.

Do you mean NTLM?

Right, this requires NTLM to authenticate users. I've hacked once 
a RSP script for authenticating LAN users on a W2k domain (for a 
customer). It didn't worked fully from scratch, as my ntlm:// scheme 
needs some improvements to better deal with Windows security model 
(I had to make some customer specific hacks in the protocol stream). 
Unfortunately, these hacks seems lost, I can't find the script anymore 
in my archives after a quick look.

is there a way to specify config items using values defines in an 
external file?

ex: 
www.my-site.com [
	root-dir root-path-var
]

this would simplify my life a lot.  I will have 4 servers to keep 
in sync and their setup will be mostly the same but their environments 
will be different.


A lot of the information is spread out in differrent tools and things... 
it would be nice if they could all share (loading) a single file 
when they start and I know I have just one "site" administration 
file to edit to contextualize all the configs of all my rebol-based 
tools.

(some which aren't web related)

Petr: I need the access to work when connecting to a Windows domain 
or using a resource from a Windows domain.   I don't know if NTLM 
covers this adequately when wikipedia's article says "Starting with 
Windows Vista, and also with Windows Server 2008, both LM and NTLM 
are deprecated by default."  IIS allows directories to be defined 
to use Integrated Windows Authentication (I misteakenly referred 
to it as Windows Integrated Auth earlier).

LN and NTLM are deprecated in favor of NTLM2 ....

Does anyone have any example code on using either SQlite or MySQL 
with Cheyenne?

Hmm ... what do you mean? You normally run your CGI scripts, which 
can connect to SQL database, no? Dunno, how it is done in case of 
persisent connections ...

I'd gather that it's not much different from using the mysql-protocol.r 
script under normal circumstances.

Does mysql-protocol.r need to be called in each rsp page that you 
create? I see that Cheyenne has database configuaration properties 
in httpd.cfg is mysql-protocol.r already implemented in Cheyenne? 
Sorry for such basic questions but the documentation is fairly limited.

if you create an application (this requires some knowledge on how 
to do that) you shouldn't need to do that other than during the startup 
sequence, and then close the connection again during close of the 
application.

Thanks Henrik I'll study up more on app-init. It just appears that 
mysql-protocol.r is being loaded by cheyenne on startup because of 
the way database access gets defined in the cfg file.

you can do this without apps, if you want, but then you have to manage 
startup yourself. you can see variable persistence in a page using 
a page like this:

<%
if not value? 'x [x: 0]
print x: x + 1
%>

In addition to Henrik's answers, database access can be used in two 
ways, either "manually", opening and closing connection yourself 
from a CGI or RSP script (READ mysql:// prefered in that case), or 
by relying on the RSP webapp API to manage persistent connections 
(see DO-SQL function in RSP API doc).


In both cases, you need to load mysql-protocol.r. The best place 
for that is in the config file in GLOBALS section, just add :

worker-libs [
    %<path-to-mysql-file>/mysql-protocol.r
]


Usually, I define a %libs/ sub-folder in Cheyenne's folder and store 
there all the libraries used by all my RSP or CGI scripts.

Max: there's no built-in support for that currently. Correct me if 
I'm wrong, but what you ask for is a preprocessor for the config 
file, no? I guess you could define a unique template config file 
where you could use, for example, issue! values to spot all the parameters. 
Something like: root-dir #root-path-var#.


You could then manage that template from your main location/tool, 
preprocess it and then emit a working file for a given server instance 
when needed.

Thanks Doc, that's what I was looking for and that's what I suspected. 
Has SQlite.r been tested at all?

I didn't tested SQlite.r within RSP scripts.

The following sqlite driver should work with DO-SQL : http://www.rebol.org/view-script.r?script=techfell-protocol.r

Hey doc, how can we handle loops in within do-task/on-done ?
Anything i try seems to block and cause port issues.

What kind of loops? Loops are blocking in an event-driven engine 
like Cheyenne/Uniserve.

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?

I think so, you have to use async read. That is the same at all async 
servers.. cheyenne is better at this because it uses async + multiple 
processes, most of popular app servers are uniprocess these days.

I thought this scenario could be recreated using WAIT or a loop that 
takes some time. 


Here'a another scenario.. a very typical websocket use..  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?

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

ie: wait 1 second, check remote server, push back to client via socket?

I haven't yet looked at websocket stuff in cheyenne so I have no 
idea .. in general in async server also all your communications to 
other services if needed is async, that means you are using callbacks 
and similar methods, you don't wait 1 but probably some timer that 
will invoke you after 1 second

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?