World: r3wp

Never really investigated deeply such construction, but at first 
look, I don't see any  issue doing that.

I have somewhere testing script (not for uniserver) working as simple 
ftp server.

maybe I could try to rewrite it

but at this moment have other things to do

I'm looking more for client than server :)

Yes, but if you know how works server, you should know client as 
well:]

off topic oldes, but are your postgres driver fixes folded back into 
the offficial driver ?

Graham, btw., what would be needed for Rebol FireBird support? Does 
it use typical tcp scheme as mySQL e.g.? This week I met with two 
ppl using FireBird, and there seem to be no answer from Rebol part. 
Well, maybe ODBC, but that is not free ...

It has an undocumented tcp protocol .. so for Linux, there is no 
option but to move to something else

Or, to try and reverse engineer the protocol from another product

maybe someone else did this and documented it?  somewhere on the 
net... just thinking loud...

I asked a year ago on the developer list .. they said, don't even 
think about it!

there is a client java module in CVS

eh? I thought that Firebird is being regarded being one of the best 
open-source offerings? No driver documented? Strange - each language 
except the Rebol has driver, so how they did it?

hmm, wrong channel, sorry...

not if someone uses uniserve to write a driver :)

:-) How would it be usefull?

Well, hmm, why not, right?

If you're going to head IT services at this new company .. perhaps 
you could get someone to write this :)

hehe ... well, they are mostly MS based - tried their website and 
I got some aspx Microsoft db OLE provider error. Will have to talk 
to guys a bit :-)

graham: what I know, my postgres driver changes are not in the original 
version. At this moment I'm not using it as I even don't have postgres 
installed. Do you need it?

Not yet ..but wanting to make sure that forks are folded back in 
:)

Doc, does the Cheyenne version of Uniserve also have the mono-thread 
execution.  If so, what should I be concerned about with regard to 
blocking?

Cheyenne uses the latest Uniserve's version. There's no special version 
of Uniserve for Cheyenne, so it's mono-thread. Uniserve also brings 
IPC between several slave processes using the task-master protocol 
(part of Uniserve, used in Cheyenne to run CGI and RSP scripts).

The main process (Uniserve process) should only do minimal work in 
processing port events so that other events can be processed in a 
short delay, giving the feeling of multitasking with several clients.

So, you should be concerned about not doing heavy computation inside 
network event callbacks (like in 'on-received). If longer processing 
is needed, you should use the task-master service in Uniserve to 
send the request to a slave process (this has also the advantage 
of fully using the power of modern multicores processors).

To determine if you can leave the work inside the callback, just 
do some simple maths. E.g., if a request needs 50ms to be processed, 
that means that your server cannot do more than 20req/s. So it also 
depends on the load your server need to handle.

I would most likely have a lot of that going on with TRETBASE since 
the searches could take some time to produce results.

In that case, you need to rely on slave processes, each one executing 
TRETBASE. This means that you have to set up a distributed architecture, 
think about disk-writing synchronization between slaves, caches consistency,... 
All these could be easier done if we had multi-threading support 
in REBOL. It can be done without, but it's more complex and much 
less efficient.

I'm currently integrating the UniServe software stack into Syllable 
Server

Thanks Doc.

Paul, you'd still need to think about all of those concurrent consistency 
problems if you went multi-threaded. Without serialization of some 
form, concurrent use will still be an issue, whether you are using 
processes or threads.

Not discouraging you, just warning you :)

I do see the problem Brian.

Of course.

I think that Doc has the most available and supported Async offering 
right now that can even quality for my needs.

I wonder if it would make sense to make some kind of a multi-LNS 
layer over Uniserve.

Wouldn't LNS currently have the same problem as Uniserve with respect 
to mono-processing?

You could take advantage of Uniserve's task dispatch and process 
management to do load balancing between LNS servers.

Doc, what I want to do is do some text to speech using a 3rd party 
web service.  I need to download the generated wave file and play 
it by inserting it into a sound port.

The read would be blocking if I use sync read, and then playing it 
thru a sound port in my experience does interfere with async tcp.

In a nutshell, is this sort of activity suitable for a task-master 
service .. and is there a simple sample of such a service?
The task would be triggered from an RSP page

Since any client could be accessing the cheyenne server, I want a 
response returned immediately so that it doesn't block the client. 
 And the sound can be played later on ...

So, if I understand correcty, you need to download a file on client 
side from a web server without blocking on the client side ?

You can't send a response, then another and another unless you use 
Comet technologies

Which means leaving the connection open.. not sure how Cheyenne would 
deal with this

I've got Univserve/cheyenne running on localhost.  I want my client 
to ask uniserve to download a file using one of it's processes and 
then play it through a sound port.  My client uses a http request 
and wants that to be non blocking ie. return immediately.  The client 
may itself not be capable of doing an async request.

eg. 
client => read http://localhost/speak.rsp?txt=helloworld

speak.rsp
<% 

 data: read/binary http://somewebserivice/cgi-bin/to-wave?text=helloworld
	insert sound-port  data
%>
<html></html>


in this scenario the client has to wait for the response.  How would 
one send the empty result back immediately, and then process the 
request so that the client is not blocked and where the client is 
incapable of an async read

You can't send back a response to the client without ending the RSP 
processing. Uniserve is not loaded in helper processes, so you can 
issue async read requests. Is your client REBOL-based ?

Just thinking of creating a general purpose app so not necesssarily

So, I guess I just need to use call instead which is async and returns 
immediately

ie. don't wait for the result