World: r3wp

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

and if you look into cgi code in the UniServe archive, you can see, 
it identifies itself like soc/server-software: "Cheyenne/1.0"

so what is here is Cheyenne in some unfinished state

hmm.... maybe if someone was using uniserver 0.9.9 and want to upgrade, 
there was important change - instead of module/response there is 
now module/result

but 0.919 is provided with no documentation ... what is the difference 
then?

so the project - moving forward - contains encapped modules?

This was quite important difference as my scripts were still using 
response (so I was getting result = none)

I'm slowly moving forward:) after a few hours I almost have what 
I already had but using new uniserve:)

so new version, 0919 does not work s is?

it works, but you have to do some small changes:-)

as the one above

and I'm not using most of the files. (At least now)

I've got this newer Nenad's version of UniServe http://box.lebeda.ws/~hmm/rebol/UniServe-r0991.zip
(but as he said - beware, it needs several fixes and updates to become 
a 1.0 candidate)

he is in contact with you?

btw - what fixes it needs?

Yes, we had a short electronic contact :-) In this archive are the 
proxy and httpd services working without need of changes, the cgi 
test seems to give me an error so probably this will need some fix.

is Doc going to be back on Uniserve or Chayanne? Without fixed sessions 
it is mostly non working httpd server

Do you mean that sessions are non-working, or that there is something 
about non-working sessions that makes HTTP (a stateless protocol 
that wouldn't normally need sessions) not work?

I don't know what is with sessions. The uniserve seems to pretty 
good to me. I'm using it. And I think that Doc is still Reboling, 
probably just don't have so much time.

BrianH - of course if you don't need sessions, httpd is probably 
working well. I just did not understand the Cheyenne release. The 
simple demo did not work. There is a demo with screen divided into 
something like 4x4 subwindows (frames), and most of them times out. 
Doc told me session layer is about to be rewritten, then no word 
from him for another few months

Surely you are not surprised that Doc would disappear abruptly? He 
seems to have even less time than I do.

there is file %libs/cookies.r so one can take a look at it, if needed

the chayenne is just encrypted uniserve

You mean HTTPS?

I don't know how it's with https, I don't have /command

I don't know how it would have HTTPS server support, even with /Command. 
I thought /Command only has SSL client support.

well, command can read https pages...?

ok... doc' seems to be online now, as he emailed me almost immediately:


I'm aware of this problem (cgi and paths). It's because the encap-fs 
system is not 

correctly supported in this version of UniServe (it's ok in the Cheyenne 

package). I didn't fixed it because, with the release of Cheyenne, 
I'm 

not sure to keep the CGI support for the HTTPd service in the UniServe 

package. I may just provide a static HTTPd server with hooks to extend 

it or embed it in user applications. v1 of UniServe have to be very 
easy 
to embed in any app (that's one of main goals).

Reading is client-side SSL.

Sessions are broken in cheyenne.  Basically session data from one 
client ends up as session data in another :(

Rebol can't do server side SSL ... Carl thought it could by changing 
a flag, but it does not work when it was tested.

So, without server side SSL, Cheyenne can't do https .. unless it's 
thru stunnel.

Rebol can't do server side SSL
 - close but no cigar, actually, it is not that hard