World: r3wp

Yep, got both at the same time too. Could the lag between the button 
click and the response be reduced? I guess that having all the voice 
processing done locally (using a REBOL app) could make it realtime?

How much data does it send to the client browser for, e.g. "hello 
word"?

The first message takes some time.. every repeat is quicker.

Got your last message 3 times...looks like a cache or block needs 
to cleared.

to <be> cleared.

i clicked it 3 times in rapid sucession.

I have a forever loop that checks the processing of the TTS.. once 
it's ready, it pushes it.. That's where the lag comes from. But then 
the .ogg file is cached, and much faster.

Oh, it was just a cheering up! :-)

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