World: r3wp

It should be possible to integrate it in R3 by rewriting the network 
part of the host kit (if both licenses are compatible).

while I am throwing in these libraries .. have you heard for mongrel 
http parser ?

I've heard of Mongrel server. What's special with its http parser?

mongrel is a server for ruby .. but it has a open sourced http parser 
that is written in "ragel" which is engine that makes some fast and 
lightweigh C code out of state machine specification. it's known 
as to be very fast and very robust because of that ( I listened too 
much online video talks in my life ) ... I will try to find some 
links

http://www.complang.org/ragel/

http://www.zedshaw.com/essays/ragel_state_charts.html

Ah, thanks for the info, I'll check the parsing rules used (that's 
a real PIA to get it right *and* secure). For the speed concern, 
a PARSE-based solution shouldn't be much slower than a C parser.

http://vision-media.ca/resources/misc/ragel-examples-- look here 
.. maybe this is the specification find "Mongrel HTTP 1/1"

ha , this is similar as more advanced rebol parse :)

I mean more advanced usage of rebol's parse

yes, I imagine http to get fully officially right is a major pain

At first look, Ragel relies on callbacks on matched patterns, so 
not a good fit for R2.

aja.. didn't look that far .. I thougth it parses given input and 
gives some result , but because result is complex callbacks might 
be nevesarry ..

**if** you found it's worth it you could make callbacks in c .. collect 
the result and only return it to rebol as data

but for the starters it requieres worka and time to discover if it's 
even worth it

I saw some huge graph one time as "whole HTTP spec" .. it was huge, 
and worying how complex it looked .. I will try to find it

I think that parse is powerfull enough to handle such parsing task. 
But finding common patterns out there might be helpful ...

Yes, surely parse can do it... I am just debating .. I am not sure 
if mongrell is really that awesome.


I was thinking that speedwise the upper bound of the http server 
is determined by socket handling and http parsing probably? Meaning 
that even if you have everything in ram and prepared you can't serve 
more thatn that. Cheyenne has a *very* high upper bound for a dynamic 
language (I was many times expressing my surprise and getting 250 
req/s was the reason I returned back to rebol with doing all webapps 
in it now).

for example of mongrell .. you typically run multiple (like 5) mongrell 
servers with ruby behind a nginx.. cheyenne does all this by itself 
so cheyenne also uses multicore /cpu better than other dyn lang servers 
by default. I am just thinking outloud if there are any prospects 
to make cheyenne/uniserve even more blazing if needed in future.

this is manually improved ragel generated http parser http://four.livejournal.com/1033160.html

uses callbacks too

hm.. I can't find that http diagram

aha .. http://webmachine.basho.com/diagram.html.. it's horibble 
basically .. if I would create a webserver I would just make 200 
and few errors, f* with the rest :)

Thanks for the diagram, there's probably a few branches that I could 
add to Cheyenne for better HTTP standard support.

Improving Cheyenne/UniServe: adding multithreading could make it 
scale much higher with much lower memory footprint. Currently, the 
main process stabilizes around ~20MB after a few hundred requests 
and each worker process take ~15-20MB depending on the application 
and loaded 3rd-party librairies. So for a server script what would 
take 1s to complete, supporting 100 clients simultaneously would 
require today ~2GB of memory. This is huge. 


Carl stated recently that threads overhead is 1MB, so with multithreading 
support, the memory usage for such use case would drop to ~100MB, 
which is an order of magnitude lower (not mentioning the speed gains 
and code simplifications resulting from dropping TCP-based IPC).

That's the main improvement that could be made internally in Cheyenne. 
Other external improvements could be to use a fast load balancer 
like nginx dispatching requests over several Cheyenne instances (over 
multiple machines), or building more advanced clusters where each 
node would be a Cheyenne server with session exchanging abilities 
between nodes.

For the "IRC" client, I'm not clear on how to build the list of ports 
in Uniserve for all connected users. On the on-new-client function, 
do I do something like append shared/client-list self?

Looks like I should be doing append shared/client-list client instead.

Briefly, can someone tell me the difference between Uniserve and 
Rebol/Services ?

R/S is a network protocol, mostly used for RPC. Uniserve is an infrastructure 
you can use to build network protocols on. For instance, the Cheyenne 
web server is built on Uniserve. For that matter, at one point someone 
built an R/S implementation on Uniserve.

nve - R/S were never properly finished. And for R3, Carl has lighter 
network services in mind. I would not bet on R/S for now ...

ok thx, I'm going to go deeper in Uniserve.

As Brian says, they're largely complementary. UniServe is mostly 
about the transport layer, while RebServices is mostly about the 
messaging layer

I wonder how it would work to partner my smtp ( receiving server 
) with the smtp ( sending ) functionality available in Cheyenne

Only one way to find out

My frustration with the iphone is the cause of this enquiry

Graham: merging both smtp servers codebase could be a good option 
and a way for Cheyenne to get 7-bit SMTP server support (which it 
is lacking currently, so classified as still "experimental").

I've started using UniServe in a production, should I use the one 
comes with Cheyenne or UniServe-r099?

The one from Cheyenne package.

No official documentation, but change-log is enough I think, right? 
(And services/protocols in Cheyenne as examples)

Exactly. You can also use the documentation from http://softinnov.org/rebol/uniserve.shtml

And for new features, have a look in Cheyenne's changelog.

Thanks a lot. I might have some questions while coding. I'm writting 
a SMS Send/Receive/Forward server & client.

Feel free to ask.

HTTPd service in UniServe is getting integrated with Cheyenne. There 
are some words & paths about Cheyenne which is not present when I 
use HTTPd without Cheyenne.

Same for task-master service. There is "uniserve/shared/server-ports" 
in "on-started" event. server-ports block is defined if we use Cheyenne. 

I made just a few extra control then able to run task-master service 
without Cheyenne. But couldn't run HTTPd

By the way, old HTTPd service (in 0.9.9 zip) runs well for HTML pages.
But gives following error when I request show.cgi file:

17/12-2:59:31.9210-[HTTPd] Method: GET - resource: /show.cgi
17/12-2:59:36.0930-[uniserve] New client: 127.0.0.1 - 9799
17/12-2:59:36.0930-[uniserve] Calling >on-new-client<

17/12-2:59:36.0930-[uniserve] << Port: 1723, low-level writing: 896
17/12-2:59:36.1090-[uniserve] Calling >on-write-done<

17/12-2:59:36.1250-[uniserve] >> Port: 1723, low-level reading: 13

17/12-2:59:36.1250-[uniserve] Calling >on-received< with {^@^@^@^-}

17/12-2:59:36.1400-[uniserve] Calling >on-received< with "[ok none]"

17/12-2:59:36.1400-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'copy
    arg2: 'value
    arg3: [series! port! bitset!]
    near: [either "HTTP" = copy/part data]
    where: 'on-task-done
] !
17/12-2:59:36.1710-[uniserve] Port closed : 127.0.0.1
17/12-2:59:31.9210-[HTTPd] Method: GET - resource: /show.cgi
17/12-2:59:36.0930-[uniserve] New client: 127.0.0.1 - 9799
17/12-2:59:36.0930-[uniserve] Calling >on-new-client<

17/12-2:59:36.0930-[uniserve] << Port: 1723, low-level writing: 896
17/12-2:59:36.1090-[uniserve] Calling >on-write-done<

17/12-2:59:36.1250-[uniserve] >> Port: 1723, low-level reading: 13

17/12-2:59:36.1250-[uniserve] Calling >on-received< with {^@^@^@^-}

17/12-2:59:36.1400-[uniserve] Calling >on-received< with "[ok none]"

17/12-2:59:36.1400-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'copy
    arg2: 'value
    arg3: [series! port! bitset!]
    near: [either "HTTP" = copy/part data]
    where: 'on-task-done
] !
17/12-2:59:36.1710-[uniserve] Port closed : 127.0.0.1

data
 is somehow none.
The error happens in on-task-done event function:


 on-task-done: func [data /local valid out value ctype body headers 
 s e][
		either "HTTP" = copy/part data 4 [  ;<<<<<<<<<<
			;--- Non Parsed Header output ---
			write-client data
		][
			;--- Parsed Header output ---
			out: ctype: line: none

Problem solved. Thanks Doc.