AltME groups: search

Ok, but this requires that I download it, install it and than take 
a look.

The wiki, once filled, will be able to give you a deep view on all 
Cheyenne's features, until that, the source package is the best you 
can have.

You can also use this group to explain your specific needs and me 
or someone else could tell you if Cheyenne is a good fit or not.

Maarten, I have between 100'000 and 200'000 rsp hits a day, many 
domains and subdomains, and other special configs, runs like a beautiful 
woman, no glitches, no problems, full speed, if it can help in your 
decision I can upload my httpd.cfg somewhere for you to have a look

Will, what do you do to get 200.000 hits a day?

Will, was it that Cheyenne instance who survived to a slashdot effect 
this year ?

yes, actually I was reading thru slashdot when I saw an article pointing 
to our server running Cheyenne, only then I went to look how that 
machine was doing (xserve 2x2.2GHz G5), I saw a little more cpu usage 
and  about 80 rsp requests/sec . I'd say rock solid! Go Dock Go (like 
Brian Tiffin like to say)  8-)

I've been steering towards a similar architecture for web serving

Well, if Will can get his Cheyenne running so stable, I gotta figure 
out what the problem is here. I did mention before that I could make 
it crash (or is it just quitting?) by clicking a specific link on 
my website, but unfortunately it's not always repeatable. But it 
does crash regularly.

If you link is pointing at a RSP page, can you send me the page source 
to ckeck it ?

Will, OSX Leopard. I think I'll wait with external testing until 
I can open my new website a few bits at a time.

Will, that's pretty amazing numbers. I'm currently using lighttpd 
for my web-sites. It's lean and clean. Maybe I should give Chyenne 
a test on my production system. What about the memory consumption?

Hm, I just spent two days getting a REBOL script to run from a graphical 
launcher in Linux

One of the many problems was that Linux chokes on the first line 
of the script, that specifies the REBOL interpreter to run with, 
if it has a DOS line ending (a CR before the expected LF)

I had to use a hex editor to debug this

Don't need it, if I press ENTER in an editor on Linux I get just 
a linefeed :-)

The problem was finding out that this was a problem, amidst all the 
other problems

always read and write in Rebol a foreign script.  Sometimes you also 
need to pass it thru detab.

some comments:

- the 52.65MB process is a memcache like uniserve service that has 
thousand of pages and partial data cached

- every task-handler process (those that process rsp) have i18n module 
that caches data in memory

If someone edits a script on Windows, when it messes with the first 
line, it won't start any more on Linux

Yeah, that is the Windows API that retrieves the values from that 
area of the registry. You will need to determine which is easier: 
Using the built-in registry APIs or creating a routine! wrapper for 
SHGetFolderPath.

though I did build a smtp server using Uniserve once ....

Cheyenne docs look a bit sparse ... the wiki sections are all looking 
for an author except for RSP. http://cheyenne-server.org/wiki/Main/HomePage

REST: The starting point is to authorize all HTTP methods by adding 
them in mod-static/method-support callback. Then, if Cheyenne doesn't 
choke on them (should be treated by default as a GET, but untested), 
you can write a dispatching RSP page that will basically do a : switch 
request/method [GET [...] POST [...] DELETE [...] ...]. The upcoming 
v0.9.19 release will bring a URL aliasing feature that will allow 
nicer and more RESTful URL.

so people asked for a wiki and then don't contribute?

as a proxy

maybe the one that asked are now too busy...anyway, the wiki was 
a good testbed for enhanced PHP support in Cheyenne.

Proxy: it can be done but requires a little more work, like building 
your own mod-something and implementing an async client protocol 
in Uniserve (unless you want to use the built-in HTTP async client 
protocol).

so, how would one determine if it's a REST request or just a ordinary 
other request?

REST = HTTP request, so it depends on which handler will respond 
to the HTTP request. If your URL point to a .rsp => RSP handler.

So your REST URLs have to point to a .rsp resource.

If you need the HTTP client for Uniserve, just let me know, I have 
a much more recent unreleased version that should work better than 
the old one in Uniserve 0.9.9.

what do you mean the REST URLs have to point to a rsp resource?

with REST you don't have a static page to point to

This release hasn't been much tested, that's what I've called it 
PR. I'll make the official release in a few days.

Watch out for regressions in your RSP webapps that might be caused 
by the new RSP sandboxing system. For those having a server in production, 
test your RSP applications carefully before upgrading.

hi doc, where can I find the syntax for the alias modul? (I wan't 
create a directory - cgi - alias)

ALIAS /url-path %filename (%filename can't be a directory)

thx doc, but what if I want to access cgi's in a directory 'outside' 
the document root?

A question about post/put

Here's my little test file

<html><title> RSP PUT test </title>
<%= request/posted
%>
</html>

I'm not at all clear on how to support a  REST call
Say, I have something like this

POST /@api/deki/pages/=patients%252F300/contents HTTP/1.0


how would i process that so the correct rsp page deals with the request?

It's a security feature to avoid saturating server's disk with unwanted 
files.

if you're doing that, you should define a dedicated virtual domain.

Other option (more powerful, but more complex), write a specific 
mod-rest module and if required, a background task handler. Not easy 
to do but could be done by copy/pasting code from mod-action/CGI 
or  mod-rsp/RSP and adapting to your needs.

OTOH, you could also make a more simpler mod-rest acting as a REST 
wrapper and just rewriting the URL to point to a simple ressource 
(CGI or RSP) and saving the REST url inside a custom HTTP header. 
That way, you could easily redirect a REST call to a RSP dispatcher. 
If you go that way, I would recommend to write a module with a single 
callback early in the Cheyenne's request processing pipeline.

Here's an untested skeleton code for such a mod-rest :

REBOL [ ]

install-HTTPd-extension [
	name: 'mod-rest
	
	order: [
		url-translate	first
	]
	
	parse-REST: func [url /local new][
		...
		do the REST url to RSP url conversion here
		...
		new
	]
	
	url-translate: func [req /local new][
		if not find/part req/in/url "/@" 2 [return none]
		
		;-- save URL in a custom header 
		h-store req/in/headers 'REST-url req/in/url
		
		;-- rewrite URL
		new: parse-REST req/in/url
		
		;-- refresh the req/in objet content
		service/parse-request-line/short new req/in
		
		true
	]
]

I see that request/posted either contains a filename, or, binary 
data depending on the size of the binary data.

I was looking for a web to fax gateway last night and found one that 
was about 10Mb using ruby on rails and a REST interface.  Instructions 
were in English but it looked like I had to be conversant with ROR 
to configure it!

Ok, I admit it doesn't do any of the other stuff that the RoR one 
does, as all it does is just send a fax.

I gather one day it might be possible to write a non-standard ftp 
hylafax protocol ... but in the meantime I guess I'm restricted to 
running the commandline utilities.

Can rebol read stdin ( eg. get the output from faxstat ) and then 
send it to a rsp page?

so a rsp page can read stdin?

I don"t see the point of a rsp page reading stdin ?

to get the output of a command line program

Use call/output to read the output of a command line program launched 
from a REBOL session.

I want to allow download of the faxes.  I made the file  names links

<a href=showfax.rsp?fax000000.tif>fax000000.tif</a>

and showfax.rsp is 

<%
recvqdir: %/var/spool/hylafax/recvq/
file: dehex request/content/filename

switch suffix? file [
	%.tif [ response/set-header 'Content-type "image/tiff" ]
	%.pdf [ response/set-header 'Content-type "application/pdf" ]
]
response/buffer: read/binary join recvqdir file file
%>

but when the file downloads,it is called showfax.rsp ...

<a href=showfax.rsp?file=fax000000.tif>fax000000.tif</a>

Graham: content-disposition should work, but there may be browsers 
or other clients that ignore it. there is a trick that should always 
work though, but i don't know if Cheyenne supports it: use a url 
like this: showfax.rsp/fax000000.tif?otherargs - you probably won't 
need to put the file name after the ? because most servers (and i 
assume Cheyenne, if this is supported) give you access to the actual 
request path.

I can try it .... but I suspect I'll get  a 404

Doc, regarding the issue above, I'm not getting the error now, but 
the content is still corrupted? ie: if I read/binary a .zip file, 
set the header to application/x-zip-compressed, the browser is recognizing 
the file size, but the file itself is corrupted? Happens with all 
binary files.

Do you have an example i can use in the embed-demo.r file that returns 
a binary?

nvm.. the response was sending back a subsequent rebol error.

yeah..  missing a comma.. 

What I meant was.. I'm using embed, and I want to pass the params 
object to other, non-cheyenne functions that I DO from the /default 
function

I've strayed from the path a bit.. I only have one function.. default.. 
then manage everything from there

Terry, that's local arguments passed to callback function. If you 
need to access them from global space, just set a global word to 
arguments value. Did you forgot how to program in REBOL ?

What I need is a PHP lobotomy

It's a little rough .. but it works.  Needs some graphical enhancements.

How about making it a Rockstar module?

Graham, that's not a problem.

Nenad, if I run Cheyenne, then do something like this... (on a newer 
XP box)

a: 1000
while [a > 0][read http://mydomain.com/a: a - 1]


It blazes along fine.. but gets about half way.. then just stalls.. 
waiting.. then further results will just trickle in.. stall.. a few 
more .. etc

Why?

Memory and CPU are hardly touched?

It's not a concurrency issue, READ is blocking, so just one connection 
at a time. I run the same test here (XP-SP3) several times, no problem. 
AFAIR, the same test was running just fine on SP2.

I didn't see it as a big issue.. served up 500 pages in a few seconds.. 
just wondering why?

I built a little Memcached system if you're interested.

It's a cache (block!)of key/value pairs.. the query is turned into 
a checksum, and compared against cache, if it matches, and the expiry 
hasn't expired, it returns the value rather than calling the DB. 
 If the key isn't found, or has expired, then it pulls the query 
from the DB, and stores it in the cache.

The cache is stored in memory.. so blazing

I already use such memcache system in Cheyenne's RSP engine (but 
duplicated in each RSP process). Using a single server would reduce 
the memory usage but I would loose RSP's DB connection pooling and 
parallel queries advantages.

My memcache is slective, it only caches the queries declared by user, 
not all queries. The MySQL backend that I use already does a good 
job at general query caching.

Im using this one a little differently .. I have a central repository 
of code that runs the framework. When you fire up a copy of the framework, 
it pulls only the pieces it requires to run from the repository, 
and loads into memory. So it automates any code updates, gives a 
massive performance boost as it's in ram, and provided terabytes 
of reusable code, images, js, css etc.

Another local ram-based AtomDB handles user specific data.. and this 
is saved in a rather unique flat file system.

This is more of a  general html question, but since I'm using RSP, 
I'l ask it here.

<html>
<title>
Editor
</title>
<body>

<%

filename: to-file request/content/filename
if (suffix? filename) <> %.rsp [ quit ]
; if filename = %edit.rsp [ quit ]
either source: select request/content 'source [
	; a http post, so save it
	write filename dehex source
][
	source: read filename
]


val-tag: rejoin [ {<input type="hidden" value="} form filename {" 
name="filename">} ]
replace/all source "<" "&lt;"
replace/all source ">" "&gt;"

print rejoin [
<form method="POST" action="/hylafax/edit.rsp">
<input type="submit" value="Save">
<hr>
<textarea rows="40" cols="140" name="source" > source
</textarea>
val-tag
<p/>
<input type="submit" value="Save">
]
include-file %footer.inc
%>

Look in latest v0.9.19. By default, RSP errors are catched and logged 
in a %rsp-errors.log file in Cheyenne's home directory. It works 
well for RSP webapps, but not really tested yet for standalone RSP 
scripts (there might be some bug/issue in that case).

Production vs Debug mode. In Production mode, when an RSP error occurs, 
Cheyenne displays a general error page (or a custom one if defined 
in config file) and logs the error on server.

this was a standalone rsp page.

I have errors mailed to me and a code 204 returning to the client 
8-)

Is there a chance to use basic authentication instead of using cookies 
to access pages inside the webapp?

I need to access some images inside the webapp from a Rebol plugin.

You need a proxy.

Can a plugin manipulate the DOM of the page?

REBOL/Plugin includes a function callable from REBOL scripts, do-browser, 
that allows you to execute and retrieve the result of browser script 
code. This script code may manipulate the browser's document object 
model (DOM), giving you the ability to interact with other elements 
in the HTML page.

Just a crash involving cgi and rsp.  Static pages are still okay.

In some cases, this value can be messed up and Cheyenne doesn't seem 
able to start a new process anymore. I've made a small improvement 
in v0.9.19, but I'm unsure how if it will be really efficient.

Sounds like the erratic crashes I've been getting. I thought I had 
found a pattern, but no.

It seems that the issue is caused by helper processes being stuck 
in "busy" mode and 'pool-count reaching the max value (8 in v0.9.18), 
so that any new CGI or RSP request coming won't find a free helper 
process. I still don't see why helper processes would remain stuck 
in "busy" mode. I'll run a few tests tomorrow to investigate that 
more deeply.

If I can't store scripts above the web root for security purposes 
.. how does one store user lists etc without using a db?

An update on my web fax portal.  http://screencast.com/t/1n1HgxKH8

When I click on a fax, it gets converted to PNG and then the Rebol 
plugin in invoked.  I bring up a new window outside of the browser 
window and display the fax.

Haven't figured out how to invert or rotate the image in place yet, 
so just bring up a new window with the rotated image.

In v0.9.19, DO is a mezzanine that do some rebinding. Maybe you should 
try with *do (native DO alias).

So with the old code, Cheyenne was hanging on each time ? (I guess 
after a few requests ?)

trapped in a time loop ?

As long as you run only one webapp on Cheyenne, no problem, but I 
ran a dozen apps on some of our servers and I was facing several 
cases of name clashing.