AltME groups: search

RSP session corruption should have been eradicated since a year at 
least.

I think I have no updated my app for over a year!

I guess that's different ... you're talking about having real pages 
stored in a virtual filing system

Doc.. Im just thinking scalability / benchmarking.  I plan on spending 
my spare time over the next number of months building a next gen 
webserver using Cheyenne as the core, and I want to make sure I don't 
hit a game killer 3 months in.


i posted earlier in the Rockstar group how superior Cheyenne is compared 
to vhosts and .htaccess.. night and day.

With R2, there's not much that can be done. The performances can 
be improved a little, that's all. You can still build clusters of 
Cheyenne server to sustain a higher load (obviously the front-end 
dispatcher would have to be done in C, there's several good ones 
in open source, or if you can afford, using an Alteon-like box). 
With a completed R3 (w/multithreading), Cheyenne could be a real 
competitor to Apache 2.

It is my personal belief that the HAL 9000 started life as a Cheyenne 
web server.

Just a question about webapps... can we provide access to these also 
by basic authentication?

Suppose I implement the rest-mod, I want it be stateless so no cookies. 
 I want to pass the userid and password each time.  So, with no cookies, 
the user won't have access to the webapp.  So, does this mean I can't 
use a webapp with rest-mod?

More than a year ago.

value: request/posted

    returns a binary! value.
is incorrect I think

From memory, it returns a binary! or string! value

If it's a file saved to the web server as it's too large .. it's 
a string! holding the file name in %incoming/

Graham, I don't. Cheyenne is doing that right now on a new page I 
just created. The first version had a flaw that would not let it 
include a specific rebol include. Now I fixed it, but it keeps "bouncing 
away" from the page.

Henrik, I've had some issues with relative paths and 'do ... in Cheyenne 
'do is a mezzainine with different bindings.

Graham, ok. It's a local cache problem then.

I need a way to properly indent all my rsp code ... editing in a 
textarea ...leads to ugly formatting as I can't use tabs! :(

/posted caught me ... i keep getting image errors when writing the 
/posted to a file and then trying to view it with img src!

<script type="text/javascript" >
function tab_to_tab(e,el) {

    //A function to capture a tab keypress in a textarea and insert 4 
    spaces and NOT change focus.

    //9 is the tab key, except maybe it's 25 in Safari? oh well for them 
    ...
    if(e.keyCode==9){

        var oldscroll = el.scrollTop; //So the scroll won't move after a 
        tabbing

        e.returnValue=false;  //This doesn't seem to help anything, maybe 
        it helps for IE
        //Check if we're in a firefox deal
      	if (el.setSelectionRange) {
      	    var pos_to_leave_caret=el.selectionStart+4;
      	    //Put in the tab

          el.value = el.value.substring(0,el.selectionStart) + '    ' + el.value.substring(el.selectionEnd,el.value.length);

            //There's no easy way to have the focus stay in the textarea, below 
            seems to work though

            setTimeout("var t=document.getElementById('code1'); t.focus(); t.setSelectionRange(" 
            + pos_to_leave_caret + ", " + pos_to_leave_caret + ");", 0);
      	}
      	//Handle IE
      	else {
      		// IE code, pretty simple really
      		document.selection.createRange().text='    ';
      	}
        el.scrollTop = oldscroll; //put back the scroll
    }
}
</script>

ah, got my page working now. always a joy to build a page in a few 
minutes with REBOL.

How about returning a file! type instead of a string! value?

So, how does a particular mod get invoked for an incoming url?  
How do I get the mod-rest.r to process the urls?

So, mods are able to process the various phases as described in cheyennes 
processing pipeliine. Each module can decide whether to process a 
phase, do nothing, and /or prevent another mod from processing that 
phase.

You can trace modules activity launching Cheyenne with -vvv option. 
You'll be able to see which module executes a given callback.

Things are a lot clearer now :)

It's probably a good idea though ... makes it easy to process the 
rest requests from others

If you use a url like

http://user:[password-:-localhost]/


where is the user and password captured?  I see the browsers FF and 
Chrome immediately remove the userid/password from the address bar. 
 IE complains that it's not a valid site

I've done enough masquerading with Rebol as a http client!

Graham, as you have a fresh eye on mods building, if you notice things 
that might be improved, I'll be glad to hear your comments.

Well, I made only a few changes and got this far

http://rebol.wik.is/Cheyenne/Mod-rest

I'm creating an API, and each api word maps to a single rsp page 
inside a %rest directory.  It is up to the rsp page to decide which 
actual function is being called, and to deal with all the parameters.

I'm not a REST expert, but your code looks ok to me so far.

Tunneling Basic authentication through SSL is a wise decision.

fordidden: charset "iIl1LoO0*àçèéêù"
	allowed: exclude charset [
		#"0" - #"9" #"A" - #"Z" #"a" - #"z" "@àçèéêù*"
	] fordidden

I think you meant 'forbidden

Didn't tested the Captcha code with v19, as a workaround try to move 
the code from on-application-start to on-session or use *do (instead 
of 'do) in on-application-start.

Either that or I'm having a very non-deterministic day

Looks like I'm going to have a very few pages as entry points to 
the application ... and so all the code will only be in a few pages.

Anyone got a suggestion on how to modularise the app even more ..

the same way you would a normal rebol app? there isn't much difference 
to RSP from running functions in a console.

No experience with any of those either ... but I've got a clue now 
:)

and if you're not using a webapp?

*do is just a fallback, if 'do is crashing your code ;-). It should 
be used, but as I had some context issues while testing with my own 
webapps, I've added it as a workaround while figuring out how to 
fix those issues.

if the RSP is not inside a webapp, then 'do will just call the native 
do.

That's why I was calling since the beginning of R3, for a focus on 
R3 Core features first, to be able to port our R2 code to R3 and 
benefit from modules (and other vital features like plugins). We 
reached PITS limits a long time ago.

Anyone got a suggestion on how to modularise the app even more...

QM?

Tested -- yes it works.  I haven't had a chance to check installation 
against the latest version of Cheyenne though.

I normally just reboot ... perhaps I need to find a cleaner way of 
killing the cheyenne process.
No, just the one RSP webapp.
Not responding.

This is not so good then .. is there a way we can debug this?

It's a bug, but hard to fix because I can't reproduce it. The only 
way to fix it would be to log into a  Cheyenne server in blocked 
state, using the rconsole client.

So, if one of you can provide me with an access to a server in such 
state, I should be able to investigate on that issue.

I take it that this is a new bug .. I'm still running a much older 
version of Cheyenne from last year ... and I never saw this.

( on a different server )

Henrik, if you're running cheyenne in source mode, you should use 
the -w command line option (that will allow the generation of a %crash.log 
file if the REBOL error is catched). If your Cheyenne quits, I don't 
think that's caused by a bug inside Cheyenne, but usually by something 
like an uncatched file access error (file handles starvation, file 
access rights,...). Will had some similar issues with Cheyenne on 
OS X, I guess he could help here.

I experienced such issue a few times months ago, but not since v19.

A RSP script that would endlessly loop (or being stuck in a wait) 
could cause such issue.

You could put a couple of debug lines around your call/wait and log 
them to a file to see if your CALL always returns.

I think I could improve such issues with a timeout on RSP script 
execution in the main process (and returning an error message if 
a time limit is reached).

no, it's not the same process and helper processes where RSP scripts 
are executed, don't load Uniserve code. They just use a small client 
(%task-handler.r).

I think that's a bug in html-gen. hang on...

Wait a minute... I have to be careful here, because an error page 
is cached in safari for some reason, so even if the bug no longer 
occurs, it will still load the error page.

There shouldn't be recursion going on there, since it's just a table 
being rendered. The recursion level is 2-3 at best.

Added a page counter so I can keep an eye on that.

how many times? Few times a hour, I am really crazy :-)

The documentation wiki has been down for a while

Right, Cheyenne still has issues with PHP FastCGI reconnection process. 
In FastCGI mode, after a given number of requests (500 here), PHP 
processes kill themselves and are relaunched. This is required by 
PHP to handle memory leaking problems.

It seems that sometimes the FastCGI TCP connection remains in half-closed 
state after a PHP process dies, and my detection method is not efficient 
enough.

Making that stable is a real challenge.

From what I've understood, it's not a good practice to let PHP process 
too much requests without restarting it. Quite funny for a server-side 
technology.

I downloaded the Cheyenne source. Started the Cheyenne.r. Should 
I be able to connect via a web browser and localhost? I get Internet 
Explorer cannot display the webpage. I looked on the website for 
setup/config documents, but the document section just seems to time 
out. Is there any other service I need to start or should it be straight 
forward? I am on winxp, internet explorer.

Check listening port with "netstat -a -b" in a Windows XP command 
window and search for an application listening on the local address 
"mycomputername:http"

And I'm unable to see the documentation on the Cheyenne website (wiki). 
I only have a neverending "wait for cheyenne-server.org" that finnaly 
ends long time after with a blank page.

Right. I left it in that state to be able to study the reasons why 
the FastCGI connection is still unreliable with PHP. I'll restart 
it in a couple of hours.

I guess that RebelBB is running as a CGI app ? If it's using READ-IO, 
your issue might be caused by some limitations of my READ-IO emulation 
code. If you can send me or point me to the code, it should help 
me improve Cheyenne's CGI support.

Okay, my READ-IO emulation has been removed in the last version. 
I've replaced it with a safe 'cgi-read-io function. I plan to put 
it back soon, I think I know how to make it work reliably now.

Doc, does it affect RSP or is this solely a PHP issue?

It's a FastCGI/PHP issue only.

Cheyenne's wiki is back online. I've fixed a bug in the FastCGI reconnection 
process. Load tests seems ok. It's now under observation during a 
few days to see if it really solved the stability issue.

Interesting pattern, I'll try to reproduce that. Strange that you 
can write a log file from rconsole, something wrong with filesystem 
writing permissions ?

A possible explanation is : your RSP processes are freezing because 
of a file access issue. The main process  wait for the RSP process 
to finish and launch a new one for new request. Once the max number 
of processes is reached, your server is no more able to execute RSP 
requests.

I have a log which notes when I call an external app, and when I 
return.  There's no problem there so it's not 'call.

if anyone has code that reproduce rsp stopping working please send 
me a copy,

does it run in a webapp ?

Yes, it's a webapp

if the path of a request goes into a configured webapp in httpd.cfg

Archive just re-released with several minor fixes. Here's the changelog 
for all fixes in this new beta 0.9.19 : 

	o RSP: fixed an issue with DB cached queries synchronization.
	

 o RSP: after a request, response's buffer is now correctly reset 
 to the default buffer.
	  

 o Mod-static: fixed badly formed redirection URL when parameters 
 are present (thanks to Will).
	

 o Bug fixed in request internal forwarding clean-up code (thanks 
 to Will).
	

 o RSP: fixed an issue with localization directories having the same 
 path in different webapps (thanks to Will).

It's just a test release for users having online servers having some 
troubles with RSP. This release doesn't fix anything specifically 
related to that (maybe fix #2 may help?), it's for these users to 
upgrade their servers to the latest release (some are still running 
on 0.9.18).

The "RSP stop responding" issue is a complex issue. It doesn't seem 
related to a simple bug in RSP, it looks like it's caused by some 
user script errors that aren't caught correctly by the RSP engine. 
There's some holes in error logging in RSP, I'll work on that to 
improve the logging system in RSP asap.


I've experienced the "RSP stop responding" issue with 0.9.18, but 
never with the latest version. Will reported me that this issue occured 
several times for him recently with 0.9.19, but it seemed related 
to user script error (?).

OK
You said "15-november" :

Okay, my READ-IO emulation has been removed in the last version. 
I've replaced it with a safe 'cgi-read-io function. I plan to put 
it back soon, I think I know how to make it work reliably now.


I need a cheyenne.exe with this done. Is there one somewhere or do 
you need to build it ?

That was one of the options, the other is me writing a good READ-IO 
emulation for CGI (that won't happen soon...lack of time).

don't many ISPs allow you to get a full VM configured as you like?

Ashley .. most ISPs won't allow you to run a daemon

I would like to hear more if someone gets to use Cheyenne on them. 
(as I deeply miss a high bandwidth, high uptime Cheyenne host).

maybe if we all contribute a few $$ each , we can get a slice we 
can all share for REbol scripts

Richard offered a free host .. so it was not discussed.  however 
Richard has now gone awol

If I can get 12 people .. viz. a year .. I'll start the process of 
ordering a slice.

At that price, it seems like a steal. The question down the road 
is, who is stealing from who. :-)

All my stuff is hosted on http://www.webarama.com.au/and they've 
been pretty amenable to my other requests. Is it just a case of getting 
them to "install" REBOL for me much as Perl is? If so, which version 
of REBOL do I need? Can I get away with /base?

what about a DB?

the good thing is .. you just pay a litle more to get more ram

A colleague of mine showed me an Object Relational Mapping product 
that generates a series of DLL for .net. (Abstracts the database 
tables as objects with methods for inserts, updates, deletes, joins, 
etc..) I don't know if I am a fan of such a tool but I was wondering 
if anyone is doing something similar with rebol or if this type of 
functionality is built in Cheyenne. Is it possible to provide abstraction 
of the databases in Cheyenne using a series of RSP's, web services, 
ORM technology? What's the best approach for enterprise portal development 
with Rebol?

Hm, I have a very small data abstraction library that uses a prototype 
for a database, currently file-based - but it's not very ENTERPRISE 
:-)