The OLE Compound files have been included in the Windows API many years ago to support the OLE enabled applications such as MS Word, Excel and many others. OLE containers maintain documents that could possibly contain embedded objects create by external applications. Therefore these documents cannot be saved to the disk so easy. The OLE container (for example MS Word) must save not only data created by it but also objects created by other applications with unknown structure and requirements. The Microsoft's solution was the OLE Compound file - file that has internal file system structure. In other words the file itself contains "directories" and "files". When the document is saved MS Word saves the text in a sub-file (called stream) in the compound file, for each inner object from the document MS Word provides a stream and the application responsible for the object writes it to that stream. Thus one Word document is actually entire directory tree containing many different files.

How they look?

The OLE file has a root storage - this is the storage returned by the SFMain.OpenStorageFile or SFMain.CreateStorageFile methods. This storage may contain sub-storages and streams. The sub-storages may contain sub-storages and streams in turn. The streams and sub-storages in one storage share one namespace - i.e. we cannot have storage and a stream with the same name. In other words this is like the file system - if you think for the storages as for directories and the streams as files everything is almost the same.

The OLE file looks like single file in the file system but internally it is like the file system itself. Thus the application can keep all its data separated in appropriate number of streams, grouped and structured in storages. If the user decides to move the application data he/she must move one single file. Internally the application can do whatever is needed with the data - access certain streams like record tables, use others to store text files or images etc.

Extended features

OLE files support several extended features. One of the features that can be useful for scripting applications is the Class ID that can be attached to each storage. By using the Class ID the application is able to implement a kind of "live document". The Class ID can be used to create custom object to handle the storage's content - which is its main purpose in the document oriented applications. Even in ASP this feature may help the skilled developers to implement flexible architectures.

When to use?

Such a structure, file that can be accessed as entire independent file system, could be useful in many applications - no matter if they are OLE containers or not. To have a single file can be accessed as organized directory structure containing many files at the most convenient locations is something most developers need for their work. For example this allows multiply resources to be kept in one single file (images, configurations and whatever you want) and this can be used in any application - WEB applications, C++/VB/Delphi applications and so on. For example several files could be packed on the server and sent to the client - then the client is able to unpack them. Or WEB application may keep some data usually kept in separate files, then the application is able to load some of the files in memory streams or access them directly.