Free portable software for linux

CGI::Portable is a framework for server-generic web apps.

SYNOPSIS

Content of thin shell "startup_cgi.pl" for CGI or Apache::Registry env:

#!/usr/bin/perl
use strict;
use warnings;

require CGI::Portable;
my $globals = CGI::Portable->new();

use Cwd;
$globals->file_path_root( cwd() ); # let us default to current working directory
$globals->file_path_delimiter( $^O=~/Mac/i ? ":" : $^O=~/Win/i ? "" : "/" );

$globals->set_prefs( config.pl );
$globals->current_user_path_level( 1 );

require CGI::Portable::AdapterCGI;
my $io = CGI::Portable::AdapterCGI->new();

$io->fetch_user_input( $globals );
$globals->call_component( DemoAardvark );
$io->send_user_output( $globals );

1;

Content of thin shell "startup_socket.pl" for IO::Socket::INET:

#!/usr/bin/perl
use strict;
use warnings;

print "[Server $0 starting up]n";

require CGI::Portable;
my $globals = CGI::Portable->new();

use Cwd;
$globals->file_path_root( cwd() ); # let us default to current working directory
$globals->file_path_delimiter( $^O=~/Mac/i ? ":" : $^O=~/Win/i ? "" : "/" );

$globals->set_prefs( config.pl );
$globals->current_user_path_level( 1 );

require CGI::Portable::AdapterSocket;
my $io = CGI::Portable::AdapterSocket->new();

use IO::Socket;
my $server = IO::Socket::INET->new(
Listen => SOMAXCONN,
LocalAddr => 127.0.0.1,
LocalPort => 1984,
Proto => tcp
);
die "[Error: cant setup server $0]" unless $server;

print "[Server $0 accepting clients]n";

while( my $client = $server->accept() ) {
printf "%s: [Connect from %s]n", scalar localtime, $client->peerhost;

my $content = $globals->make_new_context();

$io->fetch_user_input( $content, $client );
$content->call_component( DemoAardvark );
$io->send_user_output( $content, $client );

close $client;

printf "%s http://%s:%s%s %sn", $content->request_method,
$content->server_domain, $content->server_port,
$content->user_path_string, $content->http_status_code;
}

1;

^The CGI::Portable class is a framework intended to support complex web applications that are easily portable across servers because common environment-specific details are abstracted away, including the file system type, the web server type, and your projects location in the file system or uri hierarchy.

Also abstracted away are details related to how users of your applications arrange instance config/preferences data across single or multiple files, so they get more flexability in how to use your application without you writing the code to support it. So your apps are easier to make data-controlled.

Application cores would use CGI::Portable as an interface to the server they are running under, where they receive user input through it and they return a response (HTML page or other data type) to the user through it. Since CGI::Portable should be able to express all of their user input or output needs, your application cores should run well under CGI or mod_perl or IIS or a Perl-based server or a command line without having code that supports each types individual needs.

That said, CGI::Portable doesnt contain any user input/output code of its own, but allows you to use whatever platform-specific code or modules you wish between it and the actual server. By using my module as an abstraction layer, your own program core doesnt need to know which platform-specific code it is talking to.

As a logical extension to the interfacing functionality, CGI::Portable makes it easier for you to divide your application into autonomous components, each of which acts like it is its own application core with user input and instance config data provided to it and a recepticle for its user output provided. This module would be an interface between the components.

This class has 5 main types of functionality, or sets of properties that exist in parallel but are fully/mostly independant from each other. As such, it could conceptually be split into 5 physical modules, some of which could be used on their own, but they are actually contained in this one module for simplicity of use (just one object for user code to keep track of). The 5 functionality sets could be called: Errors, Files, Request, Response, Misc.

Libconfig is a configuration file processing library that saves you from having to write your own configuration parsers and routines.
This project supports callback functions, automatic variable assignment, and many different configuration file types such as Apache-like, Windows INI-like, and whitespace separated.
Configuration is processed in a logical manner: global configuration files, local configuration files, environment variables, and finally command line options.
Enhancements:
- This release adds functions to set a user-specified error string from callback handlers.
- It exposes functions to convert from a string to a specified type.
- The documentation has been slightly cleaned up.