# Overview

EventDance is an open source library for interconnecting heterogeneous applications in a simple, secure and scalable fashion. It provides a nice API to send and receive data among distributed applications over different types of transports. This and other features like cryptography, make EventDance a perfect choice for peer-to-peer application development.

## Key design features

This chapter discuss the basic design concepts behind EventDance. Not all features are implemented at the moment, but they surely will be at some point. Thus, by now some of the items in the following list should be considered a declaration of intentions, or goals.

EventDance should be:

- Asynchronous

  All activity is driven by a main event loop, which no routine should block under any circumstance. If some blocking operation is to be performed, a separate thread shall be spawned for it. All network and disk IO is expected to be non-blocking, both in the core of EventDance and in programs using it.

- Secure

  Basic API should be provided for peer authentication and data privacy/integrity at a cryptographic level.

- Scalable

  All components should scale reasonably well under high-concurrency situations, and support graceful service degradation in case of excessive load. Any mechanism available in the platform to optimize responsiveness should be used to guarantee scalability.

- Introspection friendly

  Libraries are designed to work fine with GObject-Introspection. APIs are well-thought to be used in high level scripting languages like Javascript and Python. Thus, it's a design requirement to have introspection friendly and easy to use APIs, and to always have updated GIR information.

- Extensible

  Libraries should be designed so that developers can efficiently modify or extend its behavior, reusing as much code as possible. For that, relevant parts of libraries' internal logic is published as well. See chapter Extending EventDance for more information.

- Energy efficient

  This is relative to how synchronous operations and idle states are managed. Routines in the framework or in programs using it should avoid polling continuously for a condition change, unnecessarily feeding the event loop at intervals. Instead, these operations should be moved to a thread and blocked permanently when possible, until a notification of a condition change wakes up the thread.

## Basic concepts

@TODO

## Architecture

@TODO