web notes - a blog

If you are developing code for interpretive languages such as PHP & Perl, consider the use of the scripts carefully.

As a rule, you should strive to write code which evaluates only the code required for execution. Files should be as small as possible. This is especially important for scripts that run frequently or must be fast.

Key areas to check:

• Use of ‘library’ files - large files with a collection of unrelated functions that support several types of scripts. These almsot always require the including files to read code that won’t be executed. Better to break them up by related functionality.
• Common functions should be placed in a single, small, common file. Good components include database connection functions, simple error reporting, and constants.
• Logging levels should be managed through environment variables. This allows adjustments without modifying code.
• OOP architectures should probably be avoided for files that require high speed performance.

RPM compliant web applications and toolkits must meet the following requirements:

• Dissociation of customization and extensions from the application. This includes all configuration parameters, such as database access settings, design elements, and plug-ins from the core application files. Thus, a web application can be installed as an RPM, accessed through a symbolic link, and customized for an account with the appropriate directories at the account level. In this way, multiple accounts can use the same core code, while remaining independent. This requirement can be waived if the application will be used with dedicated servers.
• Packaging with careful attention to Provides and Requires to ensure interdependencies are observed.
• Conflict resolution must be established to ensure incompatible components are not installed.

Popular web applications should consider an RPM compliant file system architecture for the following reasons:

• Disk space Most powerful applications require a significant amount of disk space. RPMs allow a single installation to serve an entire server.
• Security and maintenance RPMs can be managed with automatic updates, ensuring security and update patches are applied promptly, automatically.
• Local security Managed properly, using a common source to serve an application can allow a server administrator to provide the application, but prevent account holders from modifying it. This would be extremely valuable for hosting companies.
• Ease of installation/distribution By making RPMs available, distributing them with operating systems, and publishing them in repositories, they are easier to install and use.
• Standardization RPMs can ensure that web applications are always installed in the same place. This can be very helpful for technical support.
• Bandwidth RPMs may reduce the bandwidth required for distributing applications, by making them available from more sources.

Risks and disadvantages of this approach include:

• Loss of flexibility, all accounts will use the same core code. Extensions will have to be used to customize the applications.
• Skill level of the server administrator and application engineers must be adequate to ensure graceful use of the application within a shared architecture.
• Security, if the core code is compromised, all accounts on the server will be affected.
• Many web applications would require significant changes to use an RPM compliant filesystem architecture.

At this time, the best candidates for distribution as RPMs are javascript libraries. These libraries offer very powerful features for web sites and applications, and are very rarely changed. They are usually executed on the client side, and the CSS can be overridden easily, eliminating concerns about customization. A single symlink from the account makes them accessible for a site.