Check out the Red programming language from the same author
En /

FAQ

(This section needs an author.)

What is a webapp?

A webapp is a directory in the webspace which is protected by an authentication cookie. This directory is a container for a bunch of RSP scripts working together whilst being protected from outside access (you need to log in to get access).

Webapps provide you with automatic session handling, there are special events defined for webapps that can be used (defined in %<yourwebapp>/app-init.r) as well as support for %<yourwebapp>/public and %<yourwebapp>/private sub-folders.

Webapps are specified inside the %httpd.cfg, where there is a sample "testapp". To allow access set session/content/login?: yes and then redirect the user to a page inside the webapp.

Why doesn't Cheyenne recognized previously defined words?

Note that if you define a word! in a RSP script or in %app-init.r event handlers, it will only exists in the worker process context where it was called. It won't be defined in the other worker processes, so it will likely produce errors in your app.

The only safe and multiprocess way is to use the session object instead. This means that you currently can't have such thing as webapp global words (but you can have that at the session level).

What is a Virtual Host?

A Virtual Host is used when you want to serve different websites from the same physical machine. For each HTTP-request, Cheyenne has to decide which website a client is addressing. It does so by examination of the host names included in the client's request (name based virtual hosts). Like any other web server, Cheyenne extracts the virtual domain from the value of HTTP "Host" header and maps this to the domains defined in the config file. If no one matches, the 'default' domain is used.

Configuration of virtual hosts is set up in %http.cfg, see Config for details on this.

(Are IP-based virtual hosts possible, too?)

Why is DO-SQL not working with MySQL on my Linux-box?

Out of the probably many reasons for why that is, two major configurational hurdles come to mind: To properly connect to a MySQL Database, you have to first make sure that

  1. the %mysql-protocol.r is loaded as a worker-lib in %http.cfg's worker-libs-section and
  2. that MySQL is configured to accept tcp-requests instead of only socket-based connections.


Page last modified on November 04, 2009, at 12:31 PM
Powered by Cheyenne Web Server - © Softinnov