World: r3wp

urs -> url

hi Will, what is index.t ? could I direct 404 to some.rsp ?

yes put the path to an rsp that will act as broker in place of "index.t"

get the url with this:

url: any [select request/parsed/headers 'internal-referer request/parsed/url]

Will , thanks a lot, works like a charm :)

good so, means Dock did a great job, but that we know already 8-)

this solution with 404 also gives me the "exclude" option that I 
needed so I don't have to have some additonal map but only www.some.com/country/city/place

SVN r35 :

FIX: improved RSP script error catching involving unset! values.
FIX: fix for a rare case of RSP's response buffer corruption.

I'll update the CureCode server with this new version in a couple 
of hours.

Does Cheyenne produce error log? I can see directory called /log, 
but I can see only default-access file in-there ...

Error logs: sure. Currently these logs are stored in Cheyenne local 
folder.

trace.log

why not in log directory = all in one place?

Because I didn't had time to add code to support that feature which 
is probably very low priority currently. I'll probably add a config 
option to better control log storage for the v1.

that's not really a problem - just a question on my side - was just 
wondering, if I have to turn logging-on somewhere, etc.

Hey Doc, how would you deal with an async socket (or .dll) that received 
events allowing realtime updates on a Cheyenne web page?

The page itself could poll for info via ajax / comet etc., but how 
would you interface the socket?

ie: user clicks a button on a page, send http to Cheyenne.. Cheyenne 
pushes a message via the socket, receives a response, and pushes 
the result back to the page.

I would build a new "protocol" module for the underlying UniServe 
to achieve that.

I've had an idea for Cheyenne.. using it to interface with Freeswitch.. 
there's a vacuum at the moment, and would be a great opportunity

http://www.freeswitch.org/

bzzz ... loading :-)

Is freeswithc something like Asterisk?

ah, wrong channel, sorry ...

I have my old Framewerks (Cheyenne ) connecting via tcp port.. can 
control all aspects of calls from there.. but my rebol port knowledge 
is really rusty.. don't even recognize my own code

Yeah, Freeswitch is better than Asterisk though.

There's a good article on installing Freeswitch here http://www.linux-magazine.com/w3/issue/106/Freeswitch.pdf

FreePBX (an GUI for Asterisk) is building an interface to freeswitch, 
but the code is a nightmare

Terry, you can do that with async HTTP in JavaScript (AJAX without 
the X(ML))

Look at the source of http://tryrebol.esperconsultancy.nlfor the 
JavaScript code

There's nothing specific you have to do on the web server side except 
providing the service interfaces (regular HTTP responses)

My example is only fourty lines or so and implements a complete command 
service bus; similar to REBOL/Services but much simpler, so JavaScript 
can do it

At the Cheyenne side you can use the regular Freeswitch interfaces

Yeah Kaj, it's the Cheyenne side i'm referring to.

I want to unify communications using Cheyenne (Rebol) as the middleware, 
pulling and pushing info through and to each other

ie: an event message from Freeswitch is processed via xml socket, 
processed, and pushed to a web page via comet / ajax.. and back again..

I'm not sure it makes sense to let Freeswitch initiate events, because 
you can' t push them to the web browser, anyway. The browser will 
have to poll

Maybe it would be advantageous for caching some Freeswith results, 
but other than that it would be simpler to have Cheyenne initiate 
the communications

Yeah, I'll have Cheyenne create the port to Freeswitch, and you can 
push data to a page via Comet.

I see. Interesting

I'm running Cheyenne as port 8080 on a machine that also runs IIS. 
I want to get Windows logon which IIS can force for a directory. 
  Anyone doing this already?

Terry, I've been thinking about it, and it seems to me that Cheyenne 
is not designed to support Comet well

Cheyenne forks Uniserve processes to handle requests. These are full 
REBOL instances that seem to take around 2 MB each just after initialisation

Comet requires a connection to stay open, so it looks like this will 
take a Uniserve process for each open connection. That puts a rather 
low limit on the simultaneous clients you can handle with the memory 
of one server

I'd say one Uniserve handler should normally be able to handle several 
tens of requests per second, so even when you would let each client 
browser do a poll request every second, compared to that you loose 
at least an order of magnitude in scalability with Comet

Comet requires a connection to stay open, so it looks like this will 
take a Uniserve process for each open connection.


A Uniserve process (worker process) is not bound to a given client 
connection. Each worker accepts requests from ANY client connection, 
so it can handle hundreds of Comet-like connections with a few worker 
processes as long as each request doesn't take much time. For example, 
if each request takes 50ms, with 10 worker processes, you can handle 
200 req/sec.

The UniServe engine multiplexes client requests between available 
worker processes (and fork new ones if required).

Doc - just curious - how do you know, which worker process is free 
to work? :-)

Using a busy flag associated with each worker.

The flag is set when a request is assigned to a process and reset 
when the worker answers back.

Thanks, good info