World: r3wp

there are windows utilities to see what ports are opened and by what.

netstat will tell you that 80 is open

try this http://www.microsoft.com/technet/sysinternals/utilities/TcpView.mspx

netstat -an

i found this also on a suggestion from a friend:  http://www.hijackfree.de/en/

It turns out I have a inetinfo service running which locks that port. 
 Its used in IIS but since I'm not running it I'm not sure what is 
using this process, and killing it doesn't work, as it keeps coming 
back.  I will have to investigate using another port

scary how many open ports i have for processes i can't id

I figured out how to stop the service tying up the 80 port , When 
i run this is what I get: >> do %/c/temp/rebol/uniserve/uni-engine.r
== true
>> uniserve/boot
[uniserve] Async Protocol Admin loaded
[uniserve] Async Protocol DNS loaded
[uniserve] Async Protocol FastCGI loaded
[uniserve] Async Protocol HTTP loaded

** Script Error: change expected series argument of type: series 
port
** Where: install-plugin
** Near: change pos/2 new

does the binary work for you?

yes, i think im making progress thanks for the help

do you really need all the protocols? If not, you can start uniserve 
using this way:

do %uni-engine.r
uniserve/verbose: 5
uniserve/boot/no-loop/with [
	protocols [irc]
	services  [flashd task-master httpd]
]
;do whatever here
do-events

And if you are using the Uniserve from the link above, you should 
know, that it's just a shapshot from doc's folder so you have to 
for example edit some files - for example the default prefs of the 
HTTPd as they are leading into files which don't exists.

Not really, just trying to get the out-of-box experience

hmm... maybe that's not a good expectation then

my purpose is to educate myself about servers using Uniserve as a 
starting point

just go to services/HTTPd.r file and edit the prefs

you can also change the port you are listening - for example to 8080

the file is probably not in the best shape as there are some probes 
which are probably because of debugging which was Doc making at the 
moment when he gave it here

ok thanks - do you think Rugby might be a better choice?

I don't know, I never used Rugby and don't know what you want to 
do:)

just a learning tool

what kind of learning?

I started with uniserve 0.9.9 which is stable enough for me.

to learn about web servers, and rebol commands

I'm not sure if you should not start with some older server which 
are not async

for example with this one http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=webserv.r

thanks - i will look at that

And there is another bug in the UniServe0919 - there should be this 
in the file %services/task-master/task-handler.r (the [not value?] 
check is not enough):

if any [not value? 'uniserve-path none? uniserve-path] [uniserve-path: 
what-dir]

if any [not value? 'modules-path none? modules-path]   [modules-path: 
dirize uniserve-path/modules]

if any [not value? 'uniserve-port none? uniserve-port] [uniserve-port: 
9799]

Oldes, why don't you release a fixed version ?

I just started:)

and still have some problems...

That all sounds really strange, as Doc was claiming they use Uniserve 
in production for several customers or so, for quite some time ...

Oldes - what does your task master fix fixes particularly?

Mchean - In the past I really loved Rugby - if you want to start 
with something, and learn something (RPC), it is really a good choice 
(Rugby). Very simple to use. What I did not liked was - its lack 
of asynchronicity. E.g. in Rugby you select your function of exported 
(so callable over the tcp/ip network). But if such function does 
something for 10secs, then all Rugby is blocked and it is not able 
to accept further requests.

Pekr: I'm using uniserve as well for some time, but version 0.9.9 
I found some time to look at the version 0.9.19 now so I'm examining 
it, and must say, that's just a quick pack of some files.

Maarten later on introduced so called "green threading" (?), so you 
can divide your exposed function functionality in several or many 
parts, to get better granularity. Then he introduced chaining- so 
that e.g. main Rugby process could become kind of proxy, and forward 
(chain) request to other instance. But then there were some problems 
iirc and Maarten left its development.

Uniserve is imo kind of engine we SHOULD adapt and include in the 
core. In the case of R3, using native R3 tasking ...

And don't forget, that Chayenne is made on Uniserve, it will be probably 
some more uptodate version:-)

Pekr: and if you need to process something which will take 10secs, 
Uniserve should be good in that.

yes, but its session support sucks. I really don't understand, how 
Doc could release it, as it miserably fails. Have you tried multiple 
pane demo?

At least I use it for such a scenario, which takes more than 10secs 
to process

Later on he told me session handling is going to be rewriten, but 
then he left scene for another few months probably :-)

it's not realease

he just gave us some sources to play with

I tried to contact him few days ago, and asked him for some more 
recent version. I somehow believe, that if he really uses it for 
his own stuff, he has to have some things fixed already :-)

Yes, the most recent version is newer httpd service which is called 
Cheynne :)

and do we have access to that httpd source? Cheyenne is encapped, 
no?

Yes, the encapped part is the httpd service. You can see, that in 
Cheynne archive there is a little bit newer uniserve engine - 0.9.20

(not just httpd as it is able to do for example bzip2 compression 
so it probably needs some libs)

ech.. no, the compression should be in version 1.0