AltME groups: search

But I've found a bug in the current version:
5/11-10:57:51.468-## Error in [mod-static] : Make object! [
    code: 500
    type: 'access
    id: 'cannot-open

    arg1: {/F/SVN/cheyenne-server/Cheyenne/log/h-arch.desajn.web:8080-access.log}
    arg2: none
    arg3: none

    near: [write/append join log-dir [req/vhost #"-" log-file] second]
    where: 'do-handler
] !
The #":" is not a valid char for a file name.

Revision 107 binaries now available: http://cheyenne-server.org/blog.rsp?view=23

As an archive for images collected from remote cameras. (I didn't 
write the system). The system has been live for a few years. It currently 
runs under Xitami and I'm trying to help move it to a more modern 
web server. We are hoping to move to Cheyenne.


After the system has been migrated, we would then have the possibility 
to convert it, or parts of it,  to a Web App.

PeterWood: I've fixed the missing setenv mapping for Mac OS X in 
revision 108. Here are the binaries for you to test:
http://cheyenne-server.org/tmp/cheyenne-r108-pro-osx.gz
http://cheyenne-server.org/tmp/cheyenne-r108-cmd-osx.gz

Cool Cheyenne on OSX... I will give it a try on our new server.

SVN revision 110:

FEAT: default REBOL CGI scripts are now run as normal CGI.

FEAT: new config keyword: fast-rebol-cgi. Forces running REBOL CGI 
scripts in FastCGI mode.

FIX: (Windows) CGI handler rewritten to fix environment variables 
passing.

FIX: CGI 'set-env mapping code refactored, setup errors are now properly 
logged.
FIX: CGI scripts errors are now logged in %trace.log file.

Windows binaries are available for testing:
http://cheyenne-server.org/tmp/cheyenne-r110-pro.zip
http://cheyenne-server.org/tmp/cheyenne-r110-cmd.zip

New binaries for revision 114: http://cheyenne-server.org/blog.rsp?view=24

from a client app (phone app) to my server with my data base.  like 
a json call in js

So the server, assuming it supports a callback, sends back something 
like this, which gets executed immediately:

Commuter.dataSource.setData({ ... JSON data ...});

Maybe i'm confuesed. Is the callback a function of the web server 
or is it just how I setup my cgi script?

But basicaly I guess that your framework is just using JS to get 
some data from server.

I don't think that should be called a callback. The most defining 
nature of callbacks is that they are asynchronous, and that just 
doesn't fit into the browser/web server model

So the answer is indeed that this is nothing more than a normal request 
yielding a response, where the response happens to be JSON or maybe 
even full JavaScript. This depends entirely on your own server and 
client programs, not on the intermediating web server

This is what I am sending

HTTP/1.1 200 OK
Server: Cheyenne/0.9.20
Date: Thu, 02 Dec 2010 15:33:25 GMT
Content-Length: 475
Content-Type: application/vnd.adobe.xfdf
Connection: Keep-Alive
Content-Encoding: deflate
Set-Cookie: RSPSID=XESYTVZSEFSXPQHCTITGRDQG; path=/md; HttpOnly
Cache-Control: private, max-age=0
Expires: -1


Firefox opens up the PDF referenced in the xfdf file that is downloaded.

Chrome just downloads and saves the content.  So maybe it's just 
Chrome's PDF "plugin" that doesn't understand what to do ...

A FastCGI server protocol implementation in R3.

Are requests serialised to a FastCGI server, or is the server supposed 
to multi-task them?

Both are supported by the protocol, afaik, depending on the particular 
server settings.

FastCGI requests are serialized by Cheyenne, but without tasking, 
R3 will still process one at a time, so any blocking call or long 
processing will block the whole server.

The R3 server, right, not Cheyenne?

Yes. I'm not very interested in those, because if I would make an 
app server, it would be to cache my app. I probably wouldn't want 
multiple processes of the app server, because the caching would multiply

Cheyenne has some experimental support for FastCGI multiple server 
instances (multiprocessing) but this has never been really tested. 
The balancing is very simple, distributing requests using a simple 
round-robin method. Pool managment is minimalistic, starting all 
the instances and killing them on Cheyenne's quitting, no restarting 
or failover handling.

Btw, worker processes are not equal wrt the load. The first in the 
list gets the more jobs to do, especially if requests can be processed 
fast (which should be the case in most of well-coded scripts). So, 
you get a natural "affinity" to the first worker (having the most 
code and data cached there) for all new incoming requests. 

So, in the long run, you can look at workers memory usage to see 
how the workload is spread, the first one having the biggest memory 
usage, the last one having the lowest. Looking at the last one is 
a good indicator if the number of workers needs to be raised or not, 
if his memory footprint hasn't changed since the last restart, your 
server is doing fine with the load. I should expose some workers 
and job queue usage stats to help fine tune workers numbers.

I do see the asymmetry on our server. I have also had cases, though, 
where the number of workers went above eight or to zero. I'm not 
sure if that is still happening with the recent version

So, what would you have to use server side to manage and authenticate 
the certificates?

So, I guess the next question is .. how does one determine if the 
server is overloaded?

Windows 2003 server on Ec2

Graham, if you're concerned about performances and scalability, I 
don't understand why you're considering a CGI-based solution? AFAICT, 
Cheyenne/RSP is the most scalable solution for running REBOL code 
on server-side. If a single Cheyenne instance is not enough, you 
can use a nginx front-end to server static content and dispatch the 
load over several Cheyenne instances.


Our biggest online web-app has ~800 users, with several hundreds 
logging in each day, accessing a 400MB RDBMS with millions of records 
served by a single Cheyenne instance, with 8 workers (each taking 
15 to 25MB of RAM) running on a 2.2Ghz DualCore CPU with 2GB of RAM. 
Average Cheyenne load is 2 req/s with peaks up to 100 req/s (usually 
caused by web scanners or attacks). The webapp is still performing 
well under these conditions, and we have plenty of space to improve 
performances when it will be required (with faster hw and more instances).


Also, a key factor is optimizing webapp's code, especially for the 
most used RSP pages. Btw, a profiler would be a good addition to 
Cheyenne/RSP framework.

MikeL: 

- Download Cheyenne revision 122 source package from here: http://cheyenne-server.org/download.shtml
- Open a 2.7.8 console
- Type: 
>> cd %<path-to-cheyenne-folder>
>> do %cheyenne.r

Thanks I had tried that combination a little earlier and after running 
in Windows Auth mode, I get  "Can not open server Rconsole on port 
9801" and "Can not open server Logger on port 9802" as Uniserve errors.

Thanks for the help.  R2 is listening on 9801 and 9802 now.   Next 
step is to get it to server a page.

only works local though...does not seem to read from remote server

No, you can't use remote server .. this is a security feature.

The json data has to be from the same server as the source web page

Cheyenne's ReBorCon presentation now also available in PDF format. 
The files used for the webapp coding demo have been published too: 
http://cheyenne-server.org/blog.rsp?view=25

Cheyenne reached a new milestone, as promised during the ReBorCon, 
0.9.20 is out! 

Read the announcement here: http://cheyenne-server.org/blog.rsp?view=26

All the new binaries are built using REBOL 2.7.8, enjoy!

New Cheyenne documentation available: http://cheyenne-server.org/wiki
It covers basic Cheyenne & RSP usage.

I am trying to use SAY to support EN, FR, and ES.  But only display 
one language.... possible due to wrong HTTPD.cfg.  I think I am following 
this  http://cheyenne-server.org/docs/rsp-api.html#def-33I 
put the  locales-dir %catalogs/ within the App because it was rejected 
in other httpd.cfg locations.   Can anyone SAY what I am doing wrong?

How are you testing the language? Using locale/set-lang (http://cheyenne-server.org/docs/rsp-api.html#def-61) 
or by changing the language in your browser?

Jobs are quite experimental, but should be working in the general 
case (I'm using it on cheyenne-server.org to run a batch script every 
hour).

MikeL: I've upload my testing webapp, you can get it from: http://cheyenne-server.org/tmp/test-lang.zip
And this is the configuration I've used for it:

default [
	...
	webapp [
		virtual-root      "/test-lang"
		root-dir            %www/test-lang/
		locales-dir     %catalogs/
	]
]

Cheyenne revision 126:


FIX: (Windows) issue with current OS path in source mode and REBOL 
v2.7.8.

FIX: (Windows) 'set-env function not redefined if already available 
as native.

FIX: (Windows) CGI now properly uses call.r instead of native CALL.


Windows binaries re-released on http://cheyenne-server.org/download.shtml

this will seem like a dumb question but....


anyone know how I can get worker threads in cheyenne to actually 
open a console and allow on-screen tracing?


right now I've got 4 workers and no one opens up a console screen... 
I really need this real-time tracing, since the server is being monitored 
in real-time using remote-desktop or vnc.

Script: "Cheyenne Web Server" (2-Mar-2011)
Script: "Encap virtual filesystem" (21-Sep-2009)

** Access Error: Cannot open /Users/onetom/rebol/cheyenne-server-read-only/Cheyenne/libc.dylib
** Where: do-cache
** Near: all [
    libc: load/library %libc.dylib

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ svn up
At revision 127.

so, i can't run it from source on a headless linux server, right?

doc, having issues with a handler I am building.  


my mod is using send-msg (taken from the RSP mod) in the make-response().


the handler actually pops-up and it runs the proper code, I can see 
the printing in the console.

when my god gets its task-done called, it has the proper code in 
the result....
 all seems good..   :-)

except:

   the browser doesn't get the response and it hangs (telling me that 
   its waiting for the server).

any clues?

Script: "Encap virtual filesystem" (21-Sep-2009)
make object! [
    code: 500
    type: 'access
    id: 'cannot-open

    arg1: {/Users/onetom/rebol/cheyenne-server-read-only/Cheyenne/httpd.cfg}
    arg2: none
    arg3: none
    near: [conf: load either exists? file]
    where: 'read
]

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ chmod +x www/show.cgi 

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ head -n1 www/show.cgi 
#!/usr/local/bin/rebol -c

there are so many layers and un-obvious dependencies ( and little 
details like the error code return on top of it ) in the structure 
of the server that it gets really

Mods hierarchy: there's no such relation between modules, it is more 
an event matrix as described here: http://cheyenne-server.org/blog.rsp?view=25
(slide 5)

Communications with the workers are handled by the task-master UniServe 
service. It is done with a TCP channel (Cheyenne/UniServe process 
is the server, workers act as clients). When a worker is launched, 
the first thing it does is to connect to the server and wait for 
a new job. If the TCP connection is lost, the server considers the 
worker dead and forks a new one to replace it. Workers are doing 
their best to maintain this (umbilical) link open, if they encounter 
a fatal error, they severe the link before quitting.

onetom: those ports I listed are for Cheyenne internal usage, they 
should never be reachable from outside on a properly configured server 
(requires a firewall as REBOL binds ports to all interfaces). You 
should just let the HTTPd ports be reachable from outside.

I've been using Cheyenne for personal web server for a few years 
now ... only issue was when user installed it as a service

Those "private" folders are protected from the requests by the webserver, 
but not by the OS. If an attacker finds a way to workaround the server's 
protection, better avoid giving him critical info.

running their own app server (mongrel/thin/unicorn) helped a littlebit, 
but they couldn't easily test what was returned just by the webserver 
from cache / static files

I made a start on a mod-rest but can't access it at present .. looks 
like the server has changed ip address behind nat

because im modifying the rsp source and i don't want to reload the 
server every time

ChristianE: I've commited a fix to Cheyenne public repository. It 
will be available as a new source package in http://cheyenne-server.org/download.shtml
in about an hour. But I won't build new binaries now (takes too much 
time).

No 404 here:
>> p: open/no-wait/direct tcp://localhost:80
>> insert p "DELETE /show.rsp HTTP/1.0^/^/"
>> probe copy p
{HTTP/1.1 200 OK
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:06:16 GMT
Content-Length: 520
Content-Type: text/html
Connection: close
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: -1

<HTML>
<HEAD>
^-<TITLE>RSP Test Page</TITLE>
</HEAD>
...

onetom ~/rebol/delete $ cat httpd.cfg 
modules [ internal extapp static rsp alias ]
globals [ listen [8888]    bind RSP to [ .r ] ]
default [ debug root-dir %./ alias "/test" %test.r ]

onetom ~/rebol/delete $ cat test.r 
<% print request %>


onetom ~/rebol/delete $ rm chey-*.log; rebol -qws ~/rebol/cheyenne-server-read-only/Cheyenne/cheyenne.r 
-w 0 -vvv


onetom ~/rebol/delete $ curl -X DELETE -D- http://localhost:8888/test
HTTP/1.1 404 Not Found
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:14:04 GMT
Content-Length: 53
Content-Type: text/html
Connection: close

<html><body><h1>404 Page not found</h1></body></html>


>> p: open/no-wait/direct tcp://localhost:8888
>>  insert p "DELETE /show.rsp HTTP/1.0^/^/"
>> probe copy p
{HTTP/1.1 404 Not Found
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:17:34 GMT
Content-Length: 53
Content-Type: text/html
Connection: close

<html><body><h1>404 Page not found</h1></body></html>}



u were doing 1.0 DELETE request though, but it didn't make any difference.

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ svn up
U    mods/mod-action.r
Updated to revision 131.

Automated builds are now up and running (Linux only): http://cheyenne-server.org/download.shtml

ok, so I promised a little announcement about work I have been doing 
in/with/for cheyenne...

I have built a web service module (mod) for cheyenne.
  -----------------------
  features/highlights
  -----------------------

   * extremely fine tuned to cause the least cpu hit on the server process 
   since ALL processing is done in worker processes.

   * it uses an arbitrary number of rebol script files which you assign 
   to any host in the config file. (even the default)

   * once assigned, these files are compiled dynamically (as one app) 
   by the mod and are exposed via http by the server.

   * only the functions you *chose* are *ever* visible on the web, allowing 
   you to include support libs, data and function right in your server-side 
   api.

   * no direct execution of code occurs, *ever* from the client to the 
   server, all input is marshaled, and parameters are typed to your 
   function specs.

   * allows ANY type of web api to be delivered, from REST to SOAP like 
   interfaces.

   * output is programmable, so that you can output AS  json, xml, html, 
   txt, etc.

   * interface is also programmable, so that you can provide GET params, 
   POST forms, POST (XML, JSON, REBOL native data)

   * Automatic API documentation via source scanning and function help 
   strings .  there will also be some form of comments which will be 
   used by documentation.

   * No suport for sessions. this is part of your application layer, 
   which should use https and session keys in the submitted data, if 
   you require it.

   * it takes litterally 5 minutes to convert your internal rebol code 
   into web services which obey internet standards.

   * System is auto-reconfiguring... i.e.  you don't need to close cheyenne 
   to update the service, just restart the workers.

But I'd like to take it all inhouse as it were.  So, I could use 
this to reimplement the server side SOAP services?

For me, the most trouble free Linux to run Cheyenne is Syllable Server 
:-)

Linux binaries r134 should be available in an hour at: http://cheyenne-server.org/download.shtml

having issues starting the cheyenne server from win. it doesn't find 
the system libs.


 I had a fix for the same issue in some other code I did... I'll try 
 to see if this cures the bug in cheyenne .

I'll be putting a demo server on-line probably later tonight.

wrt api server speed  adding up all the required cheyenne server 
handling and tcp xfer we get:


>> s: chrono-time    read http://localhost:81/echo.xml?value=tadam 
     difference chrono-time s
connecting to: localhost
== 0:00:00.010442948

I guess this is the only real way to pass messages back to the cheyenne 
server:
within the mod...

task-done: func [req][
	load/all req/out/content
]

im writing a json webservice and actually it's very annoying when 
i get a RSP error html page, instead of the usual rebol error.
 


debug/off should fix that: http://cheyenne-server.org/docs/rsp-api.html#def-65

noted here: http://cheyenne-server.org/wiki/Config/Persist
is it ok, or there is a better place for it?

It's in REBOL, so the templating is done on the server. The concepts 
actually overlap with AngularJS quite well, but it's serverside

So you get conceptually the same effect as AngularJS, but it goes 
through the server. One of my goals is to maximise the REBOL part 
and minimise the JS part. AngularJS pulls everything in the client 
and is thus tied to JS and the browser incompatibilities that go 
with that

Obviously it's nice to be independent from the server - if you can 
get it to work cross-browser. But I always thought we have View for 
that. Also, it seems nice to have the browser do input checking, 
but if you want a robust app, you will have to get the server to 
guard its own consistency and end up writing all input checking twice

In general, I notice that almost all web platform projects (and operating 
system projects for that matter) are either very focused on the server, 
or very focused on the client, apparently depending on the preference 
and abilities of the founders. This doesn't make sense to me: a network 
app by definition needs to deal with both sides of the connection, 
and find the best balance

s it something hardwired in cheyenne, if the extension is .r then 
is should be handled as a plain rebol script?

 Yes, .r scripts are processed as plain REBOL scripts but with the 
 addition of the whole RSP API since r100 (http://code.google.com/p/cheyenne-server/source/detail?r=100).


It has been officialy documented on the wiki only recently: http://cheyenne-server.org/wiki/Rsp/Basis
("No-template scripts" section).

Kaj: I thought it was fixed since r131: http://code.google.com/p/cheyenne-server/source/detail?r=131

http://cheyenne-server.org/wiki/En/Sandbox
i distilled what we just talked about recently.

dunno which page should be the best for hosting such info, so im 
just braindumping here for later organization

the rfc doesn't say how URIs are supposed to be analysed.    its 
up to each server to decide such issues.

Google Docs is an extensive office suite in the cloud, with a server 
backend that does such functionality

In any case. You could program something with a timer that sends 
the edit field to the server via AJAX, but you'd have to program 
the server as well

A standalone editor widget sounds more like something that tries 
not to depend on a server or HTML5

using server side character based logging of changed text shouldn't 
be a problem.   plus, if the browser breaks, when he comes back he 
finds all his text minus a word or two!


just log character changes and send them to the server at every word 
or line. when the server replies, send the next batch.

we are showing around our stuff in thailand, china, hungary while 
the server is in singapore (ec2) and we are using the non minimized 
angular.js which is 320k.

there would be no reason to use the minimized one if it would be 
compressed.

It is a waste of server resources.

you mean server connections?

the funny thing is with this angularjs framework is that most of 
the code are static files...
hardly any rsp processing is needed.

small json is generated dynamically, but even the frontend text dictionaries 
are static javascript files,

and angularjs is doing the language switch live without any server 
turn around...

With a server side framework you don't need this

It's more or less the original web server that did the ultra efficient 
event I/O that NodeJS is now also doing

Tamas, Cheyenne's main usage scenario is not in using it as a stream 
server. If you want a server which should provide large files for 
many clients, I recomend NginX as a frontend as well. Btw. you can 
see that many WordPress providers replaced Apache with NginX to provide 
cached content.

Oldes: serving a non minified 300kb javascript framework doesnt sounds 
like a "stream server" scenario.

on the other hand, cheyenne is doing the streaming in 2kb chucks 
something, iirc.
it also does compression on rsp generated pages.
i don't really understand what is all this resistance...

i happen to have a win7 laptop around. i will git it a try, if u 
can be more specific about the versions of ur environment
run http://cheyenne-server.org/tmp/cheyenne-sources-r146.zip
with http://www.rebol.com/downloads/v278/rebol-view-278-3-1.exe?

i happen to have a win7 laptop around. i will git it a try, if u 
can be more specific about the versions of ur environment
run http://cheyenne-server.org/tmp/cheyenne-sources-r146.zip
with http://www.rebol.com/downloads/v278/rebol-view-278-3-1.exe?

From http://cheyenne-server.org/wiki/Config/Struct:

Note that the embed module, if activated, will disable all the other 
ones (required for proper working of embedded mode).

OK, I may take a look. What I eed is a really simple web server, 
so if it takes too much time I'l just do a 10-liner. That's good 
enough in this case.

If you need a really simple one, they are several on rebol.org that 
could work for you, like Carl's micro web server script.

Unfortunately that woud take a while to pick apart as I have other 
pages running on that server.

It's still in Syllable Server configured for Cheyenne, though

FYI: I've been doing some web sockets testing with Cheyenne. It seems 
that the specification is still a fast moving target. The browsers 
are trying to keep up, but server implementations (like Cheyenne) 
are breaking. For example, the Cheyenne web socket samples work with 
Chrome 12 on Ubuntu, but not with Chrome 14 or Safari 5.1 on Windows. 
I'm going to try the iPad tomorrow.

Cheyenne-server.org is taking a long while to serve the wiki pages.