Olive allows flexible bootstraping.

You can define multiple root script files, like index.php, ajax.php or whatever.php.

You can define multiple application objects with different configurations.

You can execute any application object from any root script file.

No matter what application object execution started with, you can still use any control or module within that request.

You can embed an Olive application in another appilcation to enable integration of functionality or content, by simply including one root script file.

Configuration is tootaly flexible. You can setup an Olive application in such a way that only one file is ever read. Or you can setup it up to read/write everything from file, without ever using a db engine.

There are absolutely no global variables.

OliveApp acts as a central registry and resource loader/provider.

A missing resource never interrupts application execution and always raises an handlable error or message.

Every error can be handled within executing scope. Olive executables trap errors and bubble them if they are not handled/canceled by custom code.

By default Application should fail graciously and/or silently depending on configuration or custom code.

Olive requires you to follow some naming rules in order to avoid conflicts and enable some automagical behaviour, like resource type descovery.

Basically, every resource in Olive must have a unique name and it should be enough to hint it's type. Olive implements a default strategy to perform the hinting, location and loading of resources but these may be costumized when assemnling an application object.

An Olive application is strucutured in a certain way to facilitate resource location.

Olive allows you to change the default resource location behaviours.

In the future Olive will alow compiling and reading resources from optimized files.