EventDance - Documentation and Reference Manual |
---|
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:
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.
Basic API should be provided for peer authentication and data privacy/integrity at a cryptographic level.
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.
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.
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.
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.