World: r3wp

Quick questions about Uniserve:

1) Can you encap it
2) Is the http daemon reliable
3) Does the http handler support CGI/Reblets
4) Can the http daemon listen on multiple ports

Encap: You have encapping with external scripts in detective? should 
be a selfmade do then, to check authoirity. But would extract some 
files when running.

cgi: i have read yes, launches external script. i guess that part 
needs little change, encap gets scriptname as arg.

reliable - ask graham. And its donckimbel and he sounds satisfied 
with it.

multiple ports - i guess. it can run multiple protocols, as plugins. 
so run the same plugin a few times on different ports.

5) DOc has an improved version which some people got. The webpage 
sounded like he is close to replacing apache.

1 -3 yes.  Haven't tried 4.  Think it should be able to though.

1) Yes, by the use of an encap-fs script and some little changes 
in your script.

Hello, you could find a simple bench study I've made for my job about 
Uniserve vs Apache, on the Rebol Documentation Project (see http://www.rebdocproj.org/article.php3?id_article=181). 
It's in french, but with some charts.  Uniserve is very close to 
Apache 1.3 (and 2.0, not published).

Uniserve under 1.3  when trying to run the CGI example on the main 
http page. .. ## Error in [uniserve] : Async Write phase failed !

Nenad, do you have any docs on encapping Uniserve?

No, but next release includes an 'encap-fs library and an example 
of encapping Uniserve with all dependencies and modules.

How's production coming?

Next release will be out when I'll find time to package it. It also 
needs new documentation to better explain the concept behind the 
framework.

Doc - so - will you release mysql protocol as 1.0 stable?

I think that we should finally go 1.0 after all those years - your 
code is of proven quality ...

I need to first fix the "bad handshake" random issue.

it is appearing? did not know that ...

moving to MySQL channel

Looking forward to it Nenad.

Is there any progress on encryption with Uniserve protocols ?

Why does the following not work ? Anamonitor shows that the engage 
got into place, but the rate doesn't work. I seam to forget something,
 
with rebgui:

do %rebgui.r
display "test" [
    text "hello"
    do [
        face/rate: 5
        face/feel: context [
            engage: func [f a e][
                print 'bla
            ]
            redraw: detect: over: none
        ]
    ]
]
do-events


with vid:

x: layout [button "hallo"]

x/rate: 5
x/feel: context [
    engage: func [f a e][
        print 'bla
    ]
    redraw: detect: over: none
]

view x
do-events

???any help :-)

sorry wrong group

Encryption methods are application-depend, it's hard to built-in 
Uniserve's kernel a general purpose encryption for communication 
that'll fit well any case...The kernel have to remain general purpose. 
But it may provides some helping features to allow easier encryption 
integration. Do you have some design ideas how the kernel should 
help integrating encryption ?

I think the problem I had is that uniserve either uses a terminating 
sequence, or a preset number of bytes.  If the size of each "packet" 
changes with encryption, how does one cope with that?

encrypt only the data, not the protocol-infos?

Still playing around with Uniserve... this is the most underated 
piece of Rebol wrok yet.  Looking forward to the next version.

grok wrok as work

Still have this context issue though.. goes like this.. 


If I have a service, and in that service i have a "on-received' event.. 
and I put a function within that event (aka, in the on-received function 
itself.. then it works fine.. but if I try to add the same function 
to an external file, so that, when I trigger the on-received function, 
it does a DO to the external file, that function now DOESN'T work? 
 Some kind of context issue, and how do you work around it?  If i 
have a 1000 pieces of code that needs to be processed with each event, 
do i need to bury the whole thing in the service?

And if I LOAD the external file, you would think it would bind it 
all globally, but it doesn't?

I don't understand clearly what is the problem. Do you have a small 
code example ?

Again, this is a service.. 

on-received: func [data][
raw-input: copy to-string data 
if raw-input = "test" [print "works"]
]


But if I put the if raw-input = "test" [print "works"] line in a 
seperate file.. ie  process.r ,and do it like this.. 

on-received: func [data][
raw-input: copy to-string data 
do %./process.r
]


It doesn't work.. In fact, it seems difficult to put global functions 
that are truly global, anywhere.

Probably on the same note, it's hard to encap Uniserve, given the 
folder structure and the way services are loaded etc.

The way Uniserve sits now makes it more extensible if you want to 
easily add protocols, services etc., but the trade-off is complexity 
trying to do other things.

Im sure it's fine.. just trying to grok it.

I'm finding it difficult to follow what's happening.

But if that's what it takes to have a single server handling everything 
from POP to HTTP to direct TCP, then so be it.

Looking forward to what's coming down the pipe.. what features/changes 
are you adding?

try do/args ...

From the Uniserve docs.. "Your UniServe installation is OK, so you 
can now build your next killer-app ! ;-)"

I'm on it ;)

do/args ?  how would that work?

do/args %./process.r raw-input

and change your process.r script to look at the arguments.

if process.r doesn't change, you shouldn't do it anyway.

Seems it relates to this part (from the docs)  

Put all the service related code in the service definition. You can 
include external libraries of code if needed. Everything that's not 
inside the service definition block will be globally BIND-ed.

#include external libraries of code if needed

Ok.. i can add external libraries.. just after the install-service 
[ ..   BUT..

to write back to the client, you use "write-client" so if in my processing, 
but that function wont work.. it's a catch 22.

So simply put.. how can I process an incoming message using an external 
page of code, and be able to respond from that page?  

I may need to create an "OUTPUT" value (the response) and then use 
the 'write-client' function once Im back in the service ON-RECEIVED 
function?

That last bit works.. seems the global context  functions, such as 
'write-client' dont pass to the script that is being DOne

Ok.. so now I can run the external script by placing waiting till 
i finsh the external, and get back to the 'on-received' function... 
but I have a number of functions that I use to process my external 
script.. 
Do I need to load those functions with every on-received event???