Migrating from Earlier Versions
Appweb 4 to 8 are highly compatible. Code written for Appweb 4 to 6 should migrate to Appweb 8 with few changes required.
If you are migrating from Appweb 1-3, you should regard Appweb latest as a next generation web server. You can migrate code from Appweb 1-3 to Appweb latest, however, you should anticipate significant refactoring work in the transition, especially with regard to memory allocations.
Migrating to Appweb 8
Appweb 8 adds support for the HTTP/2 protocol. HTTP/2 is a higher performance binary protocol that supports multiplexing multiple request streams over a single network connection. This necessitates some API changes and so applications, handlers and filters may need some minor refactoring to work with Appweb 8. See the separate document Migrating to Appweb 8 for details.
Changes in Appweb 7
Appweb 7 removes deprecated APIs and contains bug fixes. There are no major new features.
Changes in Appweb 6
Appweb 6 APIs are substantially compatible with Appweb 4-5, though previously deprecated APIs have been removed.
Changes in Appweb 5
Appweb 5 APIs are substantially compatible with Appweb 4, though previously deprecated APIs have been removed. The following new capabilities were added for Appweb 5.
- 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+ 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.
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. See the separate document Migrating to Appweb 4 for details.
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.
Appweb version 4 to 8 include 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. If you are upgrading from Appweb 1-3, you will need to change how you are doing memory allocations.
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.