Voici quelques-uns des dispositifs proposés par les bibliothèques Epeios :
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 œuvre d'un mécanisme client/serveur est réduite à sa plus simple expression. Nul besoin de se préoccuper 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 monotâche/mono-utilisateur pour alléger l'application (pas de mise en œuvre de sockets), ou pour en faciliter le débogage.
Même principe que ci-dessus : concevez votre CGI comme une application monotâche, les bibliothèques Epeios se chargent se chargeant de la persistance des données, les CGIs basés 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 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 mono-utilisateur/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++, à l'aide d'un fichier XSL (http://cvs.savannah.gnu.org/viewvc/*checkout*/epeios/epeios/stable/bkd4cpp.xsl?content-type=text%2Fplain), ce qui signifie que cette API pourrait être générée dans un autre langage en créant le fichier XSL adéquat.
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, constitué de balises et d'attributs, ayant l'allure suivante :
Target[type="server"]/Address
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.