The plan is to extend the online udpate system to be able to update both the core module as well as framework code which is all the parts of freepbx that are not located in the module directory. The current plan is as follows.

Core
Moving Core from its current location to the module repository mostly works today. There are some indirect expectations that core is installed and available by the framework, such as AUTHTYPE=database mode which uses the ampuser table to lookup users, and that table is accessed by one of the core module components. There are ways around this such as forcing a virgin install to be in AUTHTYPE=none which effectively it is anyhow since there are no users created yet.

However, bringing up a system without Core installed can get a bit confusing to the user, so the ideal situation is to install with Core included, but yet have it upgradable through the Online system. This is the planned route. We will Achieve this by allowing Core to be housed in the module repository but package it with the tarball during an initial install. That process is described after intoducing framework.

We will also move several conf and script files to core. These include extensions.conf, sip.conf, iax.conf, dialparties.agi, fixlocalprefix, etc. Once placed in the proper directory there is an existing mechanism that auto-links these files to their appropriate place as part of the installation process. These can then be updated with bug fixes by upgrading core

Framework
In addition to Core there is the Framework code which includes all the FreePBX web code required to make core function, in addtion to other key components such as retreive_conf and various other parts. In order to provide a facility to upgrades these components, we will introduce a new module called framework that will serve the purpose of installing patches to any needed files. The module itself will be nothing more than a module.xml file and an install.php script. The module's actual contents will be generated any time publish.pl is exectuted from the framewok module. It will be packaged as part of the module tarball but will not be checked in to svn. At publish time, the following will occur:

PSEUDO CODE:
// $fwbranch represents the current branch we are in.
// $framework is the name of the module
//
// Note there are several files such as extensions.conf, sip.conf, iax.conf, agi scripts, etc.
// that are moved to the core module already and will be auto linked by retrieve_conf and handled by
// Core as appropriate. This provides an example, it is not final.
//
rm -rf $framework/agi-bin $framework/bin $framework/htdocs
svn export https://svn.sourceforge.net/svnroot/amportal/freepbx/$fwbranch/amp_conf/agi-bin $framework/agi-bin
svn export https://svn.sourceforge.net/svnroot/amportal/freepbx/$fwbranch/amp_conf/bin $framework/bin
svn export https://svn.sourceforge.net/svnroot/amportal/freepbx/$fwbranch/amp_conf/htdocs $framework/htdocs
rm -rf $framework/recordings/includes/main.conf.php

As a result of these files being exported, the framework module now has copies of the most recent code which inevitably includes some bug fixes (or it wouldn't be published). The install.php script is aware of this file structure and simply moves forward when a new update is executed and copies the various files to their required location.

Release Tarball Generation
The tarball packaging process needs some minor modification, it will proceed as follows:

• Set the core and framework version numbers to: main_release_number.0
• Set the dependency of that module to the main_release_number
• Make sure the modules are checked-in
• Go through normal steps up to where the tag is created as outlined in Preparing for a tarball release.
• Do an svn copy of core and framework into the tag (under amp_conf/htdocs/admin/modules)
• proceed with the normal packaging
  

Doing the svn copy of core and framework into the tag will resut in the proper tarball being generated since it comes from the tag. Note that framework doesn't actually include anything but the install.php and module.xml script so there is not real content generated from it. The real framework is actually in the tarball.

install_amp implications
The scenario that has to be addressed and thus handled by install_amp is someone who had upgraded a system through the module admin, and then goes back and does a reinstall of the tarball. In that instance, framework has its shell (module.xml and install.php) installed as part of the tarball but the actuall tarball has older versions of framework code installed potentially. Also, older 'core module code may be included in the tarball. This means that the installation is going backwards from potential framework and core online updates that may already have been done and reflected in the database. In order to handle this case, install_amp will be modified to check both core and framework within the tarball, and if found it will reset the version number, as well as enable, both of these modules so that the system will be set correctly and the online system will allow it to pull upgrades again.

If installing direct from svn, a system will not have these two modules so install_amp will not change the version number and it will remain proper.

Using Framework and Core Online Updates
Discretion will be taken using this new upgrade system since both Framework and Core are critical to the functioning of the system. Furthermore, this upgrade mechanism is not designed to handle schema changes. Such changes should not be needed as they usually imply new features which should not be introduced through such a system. Any big changes of this sort should be done with a new tarball release. And within a branch, once stable (post beta/rc programs) - new features should not be introduced anyhow.