World: r3wp

OK, http://localhostworks. I have a lot to learn, as you can see. 
Thanks for helping me through this. I was just clicking on the index.html 
file in the www folder.

Can you make the session storage server a RebService, called from 
the various processes that need to read/write the data? That overhead 
might be less than the SQL overhead.

I haven't had a chance to review the Cheyenne source yet. Are the 
subprocesses called by a central broker? Perhaps that broker can 
manage the session data. That way any in-process accesses could be 
almost as fast as straight block access, with only API overhead.

Brian, that is exaclty how sessions are handled right now. Sessions 
are managed by central broker uniserve with service httpd.r and data 
exchanged with task-handlers subprocesses executing rsp

Well, if you package the session data in a manager API, you can export 
that API as a REBOL Service that subprocess can use as well.

are rebol services stable and fast?

Not sure. I remember that there was a version built on UniServe, 
same as Cheyenne, so we could use that.

Or was it built on BEER?

It's BEER I guess, not UniServe/

Does the REBOL/Plugin work with Cheyenne?

Doc, please see my posts in the Plugin-2 group.

Also, would be nice to have a link on your Cheyenne page to your 
Cheyenne blog.

REBOL/Plugin: yes, as any other HTTP client.

Blog: I'll add it this WE, I'm still doing adding some features to 
the blog, I'd like to test it a few days more with a low traffic.

I'd love if there were an LNS implementation built on UniServe. This 
would let you turn Cheyenne into a general purpose app server.

general? Rebol general,no? maybe XML-RPC would be interesting for 
non-rebol world, but it could be added too ....

I've been thinking of LNS syntax shims that would allow REBOL services 
to be called by non-REBOL clients.

Does Cheyenne have an option to limit which network adapters it will 
serve to? For example, I have 5 adapters on this computer (ethernet, 
wireless, 2 VMware, Hamachi), maybe 6 counting localhost, and I would 
like the web server to only be visible to the virtual adapters, not 
even opening a port on the physical ones.


I remember this being difficult in REBOL, that REBOL would always 
open server ports on all available adapters, so you would have to 
inspect the incoming connections and filter. Have you come up with 
a better workaround for this, or a way to do it properly?

IIRC via set-modes/get-modes, you can know what adapter is involved. 
I am afraid there is no other way how to prevent this. Opening a 
socket is OS thing imo, and I wonder if C socket functions allow 
you to choose your device?

They do, AFAIK. I do have the standard Windows firewall installed, 
but it would be better (lower overhead) to just not open the port 
on the wrong adapters in the first place.

It can be done at the C socket level, unfortunately, I don't know 
any way of doing that from REBOL.  I guess that's not supported in 
the current REBOL port!.

Can Cheynne support Ajax ?

Does each http request spawn a new instance ?

Ajax is sending standard HTTP requests, so yes.

you mean a new REBOL process ?

yes.

or uniserve task

Can RSP pages retreive content using async http and return them to 
the client?

HTTP requests for static ressource are handled in multiplexing mode 
by the main Cheyenne process. Only CGI or RSP can currently spawn 
a new process if there's no free process available to handle the 
job.

Async in RSP: there's nothing preventing that from being used.

Good to confirm this

I haven't downloaded your latest versions yet .. is a console visible 
?

Only for the main process, console are hidden for bagckground processes.

Can that be hidden as well to use Cheyenne as an embedded web server?

Of course, just add 'no-window to Cheyenne.r encap header.

mod-rewrite module for powerful request URL transformations (without 
the regexp complexity!).

There's been some discussion around here on the future of .htaccess 
... the timing of this feature may be perfect.

You can find an alpha mod-rewrite here http://softinnov.org/cheyenne/blog.cgi

is is parse base, each rule consist of a match block!, a transform 
block! and a logic! to continue thru next rule or break

Doc... Have you thought about NTLM support for Cheyenne?

(maybe there should be max-width specified in the css for the code 
block in the blog)

Unfortunately, 'max-width is not supported by Internet Explorer.

but at least under rest of the browsers it would looks better (and 
with overflow: scroll)

(overflow: auto)

This is working for IE and FF and should be added to Carl's blog 
as well:

pre {font: bold 10pt "courier new", monospace, console; width: 630px; 
overflow: auto; background-color: #f0f0f0; padding: 16px; border: 
solid #c0c0c0 1px;}

Thanks for your code, I'll give it a try. Btw, IE has 85% market 
share (according to a recent article on osnews.com).

The problem with the code above is, that it's fixed with for all 
pre tags, but in the blog there are at least 2 widths - one in the 
article and one in the comments

so I should rather use something like width: 90%

But it's a little bit out of topic chat:-)

Right, but thanks anyway for your help.

NTLM support: I thought about supporting that, but it's currently 
quite low priority. It would rely on win32 API, so would only work 
with the Windows version of Cheyenne.