Permet de gèrer tout dispositif de lecture et/ou d'écriture à travers un même objet. Ainsi, une fonction capable de traiter un ensemble de données issu d'un fichier sera capable de traiter ces mêmes données s'ils elles sont lues à travers une socket ou directement à partir de la mémoire. L'utilisation des flux permettant de faire une totale abstraction du périphérique à partir duquel sont lues où dans lequel sont écrites les données.

N'importe quel objet s'appuyant sur les bibliothèques Epeios, qu'il soit de taille fixe (objet dit statique) ou variable (objet dit dynamique), peut être stocké dans un conteneur. Ce conteneur peut lui-même être stocké dans un conteneur, qui peut lui-même être stocké dans un conteneur et ainsi de suite. L'accès aux différents objets d'un conteneur se fait par une sorte de pointeur typé, ce qui sécurise fortement cet accès (on ne peut accèder à un objet d'un conteneur à l'aide d'un pointeur destiné à un autre conteneur). En outre, on peut associer à un conteneur plusieurs structures d'organisation (liste, arbre binaire et/ou n-naire, file, pile, …) permettant d'organiser les objets d'un conteneur de plusieurs façons différentes sans avoir à les dupliquer.

Un conteneur peut utiliser classiquement la mémoire vive, ou bien un fichier (ou encore dans n'importe quel périphérique pouvant faire office de mémoire) pour stocker les données.

La mise en oeuvre d'un mécanisme client/serveur est réduite à sa plus simple expression. Nul besoin de se préocuper du multitâche, des 'pipes', de la mémoire partagé, etc. Vous concevez votre application comme s'il elle devait s'exécuter dans un environnement monotâche/mono-utilisateur, les bibliothèques Epeios se chargeant de tout l'aspect multi-tâche. En outre, on peut facilement basculer d'une application multitâche/multi-utilisateur à une application monotache/mono-utilisateur pour allèger l'application (pas de mise en oeuvre de sockets), ou pour en faciliter le déboguage.

Même principe que ci-dessus : concevez votre CGI comme une application monotâche, les bibliothèques Epeios se chargent se chargeant de la persistence des données, les CGI basé sur les bibliothèques du projet Epeios étant en fait des daemon. Et au lieu de génèrer du HTML, utilisez les bibliothèques Epeios pour mettre vos données au format XML, et utilisez toute la puissance du XSL pour mettre génèrer le HTML correspondant.

Utilisez le mécanisme dédié proposé par les bibliothèques Epeios pour séparer ce qui est propre à l'interface de ce qui est propre au traitement. Outre la facilité de maintenance de l'application, vous pourrez déployer votre application indifféremment dans un environnement client/serveur (communication via sockets, clients et serveur sur des machines différentes) ou monoutilisateur/monotâche (pas de sockets, lancement d'une seule et unique application regroupant la partie traitement et interface). En outre, l'API du backend est génèrée de manière automatique sous forme de fichier d'entête C++.

Gestion d'une base de registre, pour gèrer les paramètres d'un logiciel, à deux niveaux pour les applications multitâches ; un niveau global pour l'ensemble de l'application, et un niveau local, propre à chaque thread. La lecture ou l'écriture se fait à l'aide d'un path, consitué de balises et d'attributs, ayant l'allure suivante :

• Accès à la valeur d'une balise :

Target[type="server"]/Address

• Accès à la valeur d'un attribut :

Tables/Table[name="main"]/Language[id="fr"]/@Alias

Cette base de registre peut être remplie par un fichier (ou n'importe quelle source de données) au format XML (qui peut alors être considèré comme un fichier de configuration). Elle peut également être sauvée au format XML.

Uniquement là à des fins de maintenance.