Run PHP-driven and MySQL-driven or SQLite-driven sites off CDROM on any platform

A feature of SPWS called extensions allows functionality of web-server to be extended with third-party software. Extensions provided for download are precompiled MySQL server, PHP interpreter with various extensions and DBI/DBD perl modules for various platforms that allow to use Perl and PHP scripts to access MySQL and SQLite databases. Using demo provided on our site as template, one can build a CDROM with MySQL server, PHP interpreter, and DBI/DBD perl drivers for SQLite and MySQL for running off CD on major desktop platforms like Windows, MacOS X and Linux. Creating complex presentations that work on any platform has never been easier (if at all possible)! Request an evaluation version to try such CD in action yourself!

Since extensions are managed by Stunnix Perl Web Server, initialization like automaticaly starting MySQL server during webserver startup, automatic shutdown of MySQL server during webserver shutdown, finding a free TCP port for MySQL server to listen on, managing database files (copying them to HDD - if author specified - before starting MySQL server), rewriting PHP configuration file - all this is handled by Stunnix Perl Web Server automatically; site author just has to put MySQL or SQLite database files to a certain directories and php scripts and html, css and other files to "documents root" on CDROM and everything else will be automatically handled by Stunnix Perl Web Server. No modifications to PHP scripts are necessary at all!

The use of SPWS for CDROM creation is not the only use for SPWS - it's possible to just wrap such database- and php-driven site into platform-specific installer to allow user to install the resultant product and run it as normal desktop application.

You can request an evaluation version to try such CD in action yourself - it contains PHP and Perl scripts accessing SQLite and MySQL databases, PHPMyAmin (MySQL management software) and a sample phpBB2 forum with prefilled discussions stored in MySQL database also located on CDROM!

See a list of available Stunnix Perl Web Server extensions here.

Includes state of the art CDBuilder tool for point-and-click configuration of CD/DVD or desktop applications

CDBuilder for Stunnix Perl Web Server is an advanced tool that lets you configure all properties of your CD/DVD-ROM using GUI, without ever touching any of configuration files. You can see take a look at what options are available in "Site Settings" page of our on-site preview of CDBuilder. Just create a project, specify the location of web content and database files, what platforms to support, what scripts to enable and which extensions to enable in the scripts, database type and everything else, and click "Make Prototype"->"Copy all files" to generate a working image of your compact disk.

Stunnix Perl Web Server and web application can be packed inside a single executable file with Perl interpreter embedded, running which user gets browser-based application started automatically

Development kit is shipped with Stunnix Perl Web Server that allows to pack web server and web application with all resources, and even Perl interpterer itself and all core modules into a single executable file. Once such file is executed, it's automatically unpacked to the user's cache directory (if not already present there), web server is started and browser window is opened with browser-based application running in it. You can try such executables in action yourself - see a dedicated page to that.

All IO operations are non-blocking

The architecture of SPWS is designed to allow non-blocking IO operations and handling several HTTP requests simultaneously. All other web servers written in Perl accumulate incoming requests in the queue untill currently executed request is completely served. This means that a page which takes some time to be generated and which contains references to other resources such as images or CSS stylsheets (almost all pages do include references to them) will stay without all images and decorations until it's fully generated by a script; even instantly-generated pages will be drawn with a flicker and a visible delay if served by other web servers implemented in perl. SPWS consists of the several processes (not threads, but real processes), one of them is master process and other are slaves in which XCGI or CGI scripts are being executed. Such architecture makes it possible for master process to be always ready for receiving requests; all transfer of dynamically generated content, static content from files and passing body of client's request to XCGI and CGI scripts is performed by non-blocking IO operations, allowing not to store anything in the buffers (and thus removing the need to wait until the buffer is accumulated). This means that arbitrary large output is supported for a script, and that a user can pass files (via form fields) of any length to scripts that are part of application.

SPWS supports FastCGI-like execution framework for perl scripts that allows single process running the script to serve several http requests, resulting in ultra-fast responsibility of browser-based interface

In order to maximize responsivity of browser-based applications, SPWS supports FastCGI-like framework for execution of perl scripts, called XCGI, allowing process that runs a perl script to serve more than one http request. This eliminates perl interpreter startup time, time needed for parsing the script and time spent by initialization of the script, like opening data files or connecting to the database.

All that's needed is for each URL to be handled as XCGI script one needs to point out name of module and a name of subroutine in it that will handle http requests. That subroutine can perform all operations plain CGI application can perform - in particular use CGI.pm module for reading parameters, writing html to stdout (directly, or by the use of some templating toolkit).

Scripts that are designed for FastCGI framework can be ported to XCGI model in a couple of minutes.

Plain old CGI protocol is also supported. CGI scripts can be implemented in any language, even compiled ones; they should closely follow CGI protocol by reading input from STDIN and standard CGI environment variables and by writing output to send to the client by writing to STDOUT. Non-blocking non-buffered IO is used for interacting with CGI scripts too, so it's possible to write CGI applications that have arbitrary huge input and output.

Encoded PHP scripts are supported on all platforms

Stunnix Perl Web Server supports PHP files encoded with IonCube PHP Encoder; and Zend Encoder loaders for all major platforms (Windows, MacOS X, Linux) for PHP files encoded with IonCube PHP Encoder and with Zend Encoder are integrated into SPWS, this means that it's possible to use encoded PHP scripts with SPWS without fear that they will be studied, stolen or reworked and illegally integrated into other products. And as always, use Stunnix Perl-Obfus for protecting your Perl scripts and Stunnix JS-Obfus for JavaScript code. This ability allows product developers to use web site technologies without fear about loosing their competitive advantage and intellectual property.

SPWS is implemented in pure perl, without dependencies on external modules

SPWS is a set of Perl modules that even doesn't require installation. These modules depend only on modules shipped with any vanilla version of Perl. Since some perl vendors like ActiveState or RedHat add a lot of additional modules, it's worth to point out that SPWS works even with perl downloaded from perl.org - i.e. with smallest set of modules that can be shipped with system Perl interpreter possible).

SPWS Works on vanilla installations of any Perl interpreter versions from 5.004 to 5.8.3 (inclusive)

SPWS was tested on all versions of perl from 5.004 to 5.8.3 (inclusive). This means that your browser-based applications using SPWS as webserver will work on most Unices and linux distributions without requiring installation of Perl at all (since most Unices and linux distributions are shipped with Perl interpreter, e.g. Sun Solaris 7 and greater, MacOS X, HP-UX, even some Oracle and Rational products are shipped with Perl interpreter included).

Such wide spread of perl in default installs guarantees that your browser-based application will be ready for use on majority of OSes.

Extensively tested on Unix, Linux and MacOSX and versions of MS Windows from 95/98 and above

SPWS is cross-platform, it's a set of Perl modules and scripts that can be simply copied to any machine with Perl interpreter present and run on it. When run under Windows, SPWS provides the same set of features as when run under Unix; this was primary design and implementation goal, and a lot of efforts were required to satisfy it for running in original Windows 9x environment, even without current Windows updates.

A lot of efforts were required to hide internal implementation details of SPWS from the user on Windows 9x; these efforts allowed console windows previously appearing for a fraction of a second when SPWS is started not to appear in all cases on any version of Windows.

All features of SPWS are fully supported on MacOSX too.

No installation required, it works from any location

No installation stage for SPWS is required, it runs from any location. A special utility, shipped with it and that is suggested as an end-user mean for starting browser-based applications, automatically tunes environment and computes commandline options for SPWS to run the web-based application that depends on SPWS. This allows to create CD-ROMs containing cross-platform browser-based applications, that can be used e.g. for presentations or retail versions of the applications; such CD-ROMs can work on majority of platforms by shipping perl interpreters on such CD-ROMs and writing utilities to start perl and SPWS via "autorun" functionality for each of the platforms (sample CD is available for download).

Advanced support for client-side caching

SPWS includes means to help or force browser to cache resources used by web pages that form your application. SPWS tries to compute whether the resource cached by the browser has changed since the moment it was requested previously, and notifies the browser in case it has a fresh copy of the resource if resource hasn't changed - to avoid reloading of resource that is obviously unnecessary. This means that in most cases all images and css files referenced by the web pages will be loaded only once by the browser, after that browser will use the version of resource present in its cache.

It's also possible to mark some URLs or documents below some directory as always not changed by adding corresponding HTTP headers in configuration files, thus allowing to mark some directory as "non-changing" to avoid reloading even in case freshness of its content can not be correctly determined.

Support for plain old CGI, PATH_INFO, SSI, GET/POST requests with data of sizes arbitrary greater than amount of virtual memory available

SPWS provides support for standards supported by other modern web servers. It supports Server Parsed documents - also known as Server Side Includes (SSI), though syntax is slightly different from one available in Apache web server:

• Directives that require a CGI or XCGI request to be made are not supported (e.g. 'exec' directive)
• Support for conditional directives is present, but Perl language syntax is used for expressions (e.g. eq instead of =, ne instead of != for stringwise comparing, etc)

Other than that, behaviour and syntax is fully compatible with Apache's mod_include module. Most of the pages use most basic SSI directives like include, include virtual= and simple variable assignment, for which syntax and behaviour is identical to that of Apache.

Classic CGI protocol for execution of CGI scripts written in any language (even in compiled ones like C++) is also fully supported. CGI scripts (as well as XCGI scripts) get their environment initialized as per CGI specification, and the body of request is sent to script's stdin, and output with headers are expected on script's stdout. The input and output with CGI and XCGI scripts is done via non-accumulted non-blocking IO operations, so arbitrary large input and output for CGI and XCGI scripts are supported, even exceeding amount of virtual memory available. This is also feature unique to SPWS among all web servers written in Perl.

Apache-style PATH_INFO is also fully supported - it's very useful for a lot of purposes; in particular it greatly simplifies developing applications with a notion of per-window session identifer - by using that identifier as a virtual directory below the script name, one can pass the session identifier without need to store it in the cookies (limiting user to only one session being supported at any moment of time) or without need to add session id to all hyperlinks and forms that are used on the pages of application.

Cross-platform support for stopping of server and releasing the media

There is an advanced cross-platform support for stopping SPWS and releasing media. It's triggered by visiting any resource whoose name contains special string; after that SPWS will serve content for 5 more seconds (to allow that resource to refer to images, stylesheets, scripts and even multimedia) and then will terminate, releasing media.

Flexible configuration via Apache-like configuration files

Configuration files for SPWS have Apache-like syntax, with attempt to name all directives after Apache's directives. Most directives can be included inside <Location></Location> or <LocationMatch></LocationMatch> sections to make them specific only for resources below some directory relative to web server root or to resources with URIs matching some perl regular expression. Functionality of Apache's mod_env (for setting/unsetting environment variables), mod_actions (for defining scripts to be invoked when some specific document is requested) and mod_headers (for adding, setting or unsetting HTTP headers), all available for activation on per-location basis, is also present.

Ability to map file extensions to mime types or builtin special handlers (for handling files as (X)CGI scripts, SSI documents or plain files) is also present and available for activation on per-location basis.

Multiple configuration files can be specified on SPWS commandline; it's possible to pass lines to be treated as coming from configuration file using SPWS commandline too.

Environment CGI and XCGI scripts run in is very similar to one they get from Apache

Set of environment variables that CGI, XCGI and Server-Parsed documents get is very similar to one they get from Apache. This greatly simplifies porting scripts and documents between these two web servers.

Shipped with advanced utility to start it on any free TCP port and launch web browser

In order browser-based application to appear as native to the user, a special perl utility is shipped for starting SPWS at the first free TCP port if no instance of SPWS for that browser-based application is running yet; after that browser window fetching page from the port on which SPWS on that application is running is opened to start browser-based application. It's possible to instruct to open site in MSIE in MacOSX, independently of what the default browser is on the computer.

SPWS and all scripts that are started by it are terminated automatically without any GUI prompt when user ends session or reboots/shutdowns machine on Windows or Unix/Linux.

No limitations on number of users running independent sessions of SPWS at the same time; several browser-based applications can be run by same user on the same machine

No instances of SPWS are shared by users; it's possible to run several browser-based applications (or differrent versions of the same browser-based application) at the same time for a given user - an instance of SPWS will be running for each version of browser-based application. In other words, SPWS makes no limitations of such kind.

Hints about underliying platform features are provided to the applications

SPWS includes some support for providing browser-based applications some information about platforms and environment they run under, such hints are provided using environment variables by the wrapper script that starts Stunnix Perl Web Server on first free TCP port and launches browser with the site opened in it. This allows for browser-based applications to contain less platform-specific code.

Two licensing models available, for single application and for unlimited number of applications

SPWS is available using two licensing models - for single applications (with no more than 2 commercial editions and any number of trial or demo editions) for $239 and for unlimited number of applications for $789. All terms are listed on the Pricing page.