Migrating to Appweb Latest
This document provides some guidance when upgrading to the latest Appweb release.
If you are migrating from Appweb 1, 2 or 3, you should regard the latest Appweb as a next generation web server. You can migrate code from Appweb 1, 2 or 3 to Appweb latest, however, you should anticipate significant refactoring work in the transition.
Appweb 4 to latest are substantially compatible. Code written for Appweb 4 should migrate to Appweb latest with a few changes. Appweb 5 uses newer versions of the MakeMe and Pak tools. This necessitates some changes to the build files.
Changes in Appweb 5
Appweb latest APIs are substantially compatible with Appweb 4-6, though previously deprecated APIs have been removed.
- ESP is now a stand-alone product and can be run separately
- ESP applications are now configured via esp.json configuration files
- Appweb and ESP are now more modular and heavily use the Pak tool to install and manage extension components from the Online Pak Catalog.
Appweb 4.6+ use the MakeMe build system. New configure options and cross compiling capabilities have been added. See more details below in MakeMe Changes.
Changes in Appweb 4
Appweb 4 provides equivalent or greater functionality to that in Appweb 3. While Appweb 4 may have a different interface or API, the capabilities of Appweb 3 have been continued in Appweb 4, and in many cases, the features have been enhanced.
The following new capabilities have been added to Appweb 4 (and have no equivalent in Appweb 3). These additions should not require adjustment for applications developed under Appweb 3.
- Multi-Language support
- Embedded Server Pages (ESP) web framework
- Routing engine with request routing and rewrite
- Integrated content caching
- Enhanced cross-platform building (via MakeMe)
- High performance event loop architecture
- Extended security sandbox limits
- Flexible request tracing and logging
The following capabilities have been changed and may impact your Appweb 3 applications.
- The core Appweb Http engine has been extracted, enhanced and is now a separate library. All the APIs have a "http" prefix instead of an "ma" prefix.
- The stand-alone Appweb command line program is upgraded with new switches and options.
- The build system is upgraded and simplified. Appweb 4.6+ and Appweb 5 use the MakeMe build system. New configure options and cross compiling capabilities have been added. See more details below in MakeMe Changes.
When migrating from an Appweb version that used Bit for building, please not the following changes:
- All MakeMe files have a ".me" extension instead of ".bit".
- The generated header is now named "me.h" instead of "bit.h".
- The me.h header definitions use a ME_ prefix instead of "BIT_".
- The OS header is now named osdep.h instead of "bitos.h".
- The EGI handler has been removed and deprecated in favor of the ESP handler which has equivalent and extended functionality.
Many of the internal APIs in Appweb 4 have been changed. This is due to the utilization of a common Http library between Appweb and ESP. Appweb 3 APIs have been renamed/converted on a function by function basis to equivalent APIs in Appweb 4. The APIs have very similar names to the previous counterpart.
Appweb 4 includes a high performance memory allocator and generational garbage collector. The allocator is a fast and immediate coalescing allocator. It is optimized for frequent allocations of small blocks and uses a background collector to free unused memory.
The garbage collector is somewhat unusual in a C program. However, garbage collection is especially well suited to long running applications like a web server since it virtually eliminates memory leaks. Unlike traditional memory allocation where free must be called, Appweb 4 uses the opposite approach: memory that must be retained needs to be actively managed to prevent garbage collection. This means that a managed reference must be held for all active memory. See Memory Allocation for more details.
Migrating Appweb Configuration Files
The Appweb 4 configuration file is substantially the same as the Appweb 3. 'Include' directives can now contain wild cards and there are several new directives supporting Routing, Multi-language support and the Embedded Server Pages web framework. The big change is that Route directives replace the Directory and Location directives.
Routes vs Directory/Location Directives
Appweb 4 uses a more flexible Route directive instead of the Appweb 2/3 Directory and Location directives. The Route directive has more flexibility and allows powerful regular expression URI parsing and routing. In nearly all cases, Location and Directory directives should easily migrate to Route directives.
Migrating Modules and Handlers
Appweb 4 modules use modified API signatures to initialize with Appweb. In Appweb 4, the MPR module is pre-created and passed into the module. See the Creating Modules document for more details.
In many cases, the new Embedded Server Pages (ESP) web framework provides a simpler and more flexible way to add functionality to Appweb compared with custom handlers and modules. ESP allows the easy binding of "C" language functions to request URIs via powerful Controllers and the Appweb routing engine.
Embedded Server Pages
ESP is the single biggest change in Appweb 4. ESP is a powerful Model/View/Controller web framework that offers:
- Transparent compilation of ESP programs and web pages
- Embedded C code directly in web pages
- Template web pages with layout pages
- Caching of compiled ESP and web pages
- Caching of generated request responses
- Model/View/Controller framework
- Ajax jQuery integration and support
- Native code level performance
- Compact memory footprint
Migrating CGI Programs
CGI programs should migrate unchanged. The CGI handler in Appweb 4 offers much higher performance by using pipes for I/O instead of files.