One of the most important features introduced in the version 0.8
are the virtual containers/items.

Understanding virtual objects.

When you add a file or directory to the database via the web interface
several things happen.

1) The object is inserted into the PC Directory.
PC Directory is simply a special non-removable container. Any media file
added will have an entry inside the PC Directory tree. PC Directory's
hierarchy reflects the filesystem hierarchy
All objects inside the PC Directory including itself are NON-VIRTUAL 
objects.

2) Once the item is added to the PC Directory it is forwarded to the
virtual object engine. The virtual object engine's mission is to
organize and present the media database in a logical hierarchy based on
the metadata of the available items.

Every UPnP server implements what is here called virtual objects in one
or another way. Audio files are always sorted by artist, album, etc.
All servers known to authors have strong limitations on the structure
of the virtual containers. There is always a predefined layout of data
and you have to live with it.

In Mediatomb we try to address this shortcoming by introducing
the _scriptable_ virtual object engine. It is designed to be
- Maximally flexible
- Easily customizable and extendable
- Robust and efficient

We try to achieve these goals by embedding a scripting runtime
environment allowing execution of ECMAScript-262 conform scripts
better known as JavaScript inside the server environment.
We are using Mozilla's JavaScript implementation called SpiderMonkey.
It is a stand-alone easily embeddable javascript engine, supporting
JavaScript versions 1.0 through 1.4.

Briefly it works like this. After an item is added to the PC Directory
it is automatically fed as input to the import script.
The script then creates one or more virtual items for the given item.
Items created from scripts are always marked virtual

When the virtual object engine gets notified of an added item
following happens:
A javascript object is created mirroring the properties of the
item. The object is introduced to the script environment and bound
to the predefined variable 'orig'. This way a variable orig is
always defined for every script invocation and represents the
original data of the added item. Then the script is invoked.

In the current implementation if you modify the script you will have
to restart the server for the new logic to take effect. Even if you
restart the server only new objects will be added based on the new
logic, eventually mixing with the virtual objects created by the
previous logic resulting in chaos. Thus it is recommended to delete
all objects from the database, or simply reinitialize the database
before adding new items. This problem will be fixed in the next release


As you see, current implementation has serious limitations and inconveniences, but
the concept and engine itself have undergone severe testing and have proven
to be very stable and efficient. Now it's time for enhancing the engine.

If you are interested in writing your own scripts for your very personal
data layout, scripting-dev.txt sheds some light on this area.

My personal vision is in the end a collection of user submitted scripts
with screenshots, etc, giving a chance to non-techies to easily customize the
server by choosing from many existing layouts.