Sample configure line:

../gateway/configure --prefix=/home/seth/MobileHelix/debug-gateway-install --with-3rdparty=/home/seth/MobileHelix/3rd-Party-packages --enable-debug --with-c-common=/home/seth/MobileHelix/DeviceCommon/install/linux/x64

Dependencies
------------

This module requires:

-Apache 2.2.x - it has been tested with Apache 2.2.19.
-libxml2 - it has been tested with libxml2-2.7.8
-libzip - it has been tested with zlib 1.2.5. 	

All dependencies should be installed to the same directory prior to
begin the build procedure.

Building the module
-------------------

Consistent with apache itself, the module is built using GNU autotools
- autoconf, automake, and gmake. In order to maintain a clean
separation between source files and generated files, the first step is
to create an object directory separate from the source directory. This
directory can have any name and be in any location, although I
strongly recommend placing it separate from the source tree to avoid
accidentally checking in auto-generated files.

1) This is a one-time step, only run before your first build. From
within the source directory run the config.sh shell script. This
re-generates the configure script and generates Makefile.in in all
appropriate sub-directories.

2) Change into the new object directory and execute the following steps:

   </path/to/mobconnect>/configure --with-apache=</path/to/apache/install> [--enable-debug]
   make
   make install

The path to the apache install should be the parent directory under
which you will find the bin, include, etc. sub-directories with
apache's binary files. The --enable-debug option toggles on debugging
symbols and turns off optimization to make it easier to debug in gdb
or another debugger.

The install step uses apache's apxs utility to install the shared
library (.so) generated by the build process and it copies the
httpd.conf file generated from conf/httpd.conf.in into the conf
sub-directory of the apache install.

Implementation Overview
-----------------------

The mobileconnect module is an Apache module designed to implement a
mobile-friendly Apache reverse proxy. A reverse proxy is essentially a
gateway that acts as an intermediary between the client and a
specified list of servers. The reverse proxy configuration in
httpd.conf enumerates explicitly where the reverse proxy is authorized
to send the HTTP requests that it receives.

The module has 3 goals:

1) Provide the best user experience on the client device by modifying
HTTP traffic as it passes through the proxy to make it mobile
friendly.

2) Optimize usage of the limited bandwidth, high-latency mobile link by:
--Reducing traffic that is sent over the link through compression,
  image scaling, and caching.
--Batch communications as much as possible to avoid unnecessary
  roundtrips.

3) Provide enterprise-grade security:
--Secure connection between the client and the reverse proxy.
--Secure connection between the reverse proxy and the destination
  server(s).
--Simple authentication mechanism to ensure that only authorized
  mobile clients and authorized users access the reverse proxy and the
  applications it is linked to.

Implementation overview:

The module is implemented as a sequence of filters, each of which is
turned on/off with appropriate configuration directives. The list of
filters is as follows:

--HTML format filter: output filter that processes text/html traffic
  and outputs a mobile friendly version of the same HTML to the
  client.

--Image scaling filter: output filter that manipulates images such
  that the smallest amount of data possible is sent down to the mobile
  client. Since mobile clients have small screens, it is wasteful to
  send them large images and then have those images scaled down on the
  client. Instead, we scale down the images before we send them to the
  client.

DEBUGGING NOTES
===============

The gateway uses a named shared memory segment to communicate between
processes when an application update occurs. If you Ctrl-C to end a
debug session, that shared memory segment is not cleaned up by the
appropriate pool cleanup handler. You must manually cleanup the shared
memory segment using the following two commands.

ipcs -m
ipcrm -m <ID>

The first lists the shared memory segments in use. Look for one that
is 4 bytes and, presuming your debug session is no longer running, has
a value of 0 for "nattch". ID is the "shmid". The quoted strings are
column headings in the output from ipcs -m.

TO LOOK AT SESSIONS BY HAND IN MONGO
====================================

./bin/mongo localhost/admin
db.auth('admin', '<password>');
use session;
db.clientsessions.find();
db.clientsessions.find({ 'active' : 1 });
db.clientsessions.find({ 'active' : 1 }, { userid: 1, client: 1, key: 1 }); // Only show userid, client, key in results