1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
<part id="evd-overview">
<title>Overview</title>
<partintro>
<para>
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.
</para>
</partintro>
<chapter>
<title>Key design features</title>
<para>
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.
</para>
<para>
EventDance should be:
</para>
<itemizedlist>
<listitem>
<emphasis>Asynchronous</emphasis>
<para>
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.
</para>
</listitem>
<listitem>
<emphasis>Secure</emphasis>
<para>
Basic API should be provided for peer authentication and data privacy/integrity
at a cryptographic level.
</para>
</listitem>
<listitem>
<emphasis>Scalable</emphasis>
<para>
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.
</para>
</listitem>
<listitem>
<emphasis>Introspection friendly</emphasis>
<para>
Libraries are designed to work fine with
<ulink type="http" url="http://live.gnome.org/GObjectIntrospection">GObject-Introspection</ulink>.
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.
</para>
</listitem>
<!--
<listitem>
<emphasis>Hot-plug configurable</emphasis>
<para>
Configuration-sensitive components should provide means to change any option
on-the-fly, without needing to restart the main service. For that, a management interface
should be provided and all configuration-sensitive objects should
implement it. Examples of this are adding/removing listening interfaces on network services,
changing URLs to resources, adjusting limits like number of connections, bandwidth, etc.
</para>
</listitem>
-->
<listitem>
<emphasis>Extensible</emphasis>
<para>
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
<link linkend="extending">Extending EventDance</link> for more information.
</para>
</listitem>
<listitem>
<emphasis>Energy efficient</emphasis>
<para>
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.
</para>
</listitem>
</itemizedlist>
</chapter>
<chapter>
<title>Basic concepts</title>
<para>
@TODO
</para>
</chapter>
<chapter>
<title>Architecture</title>
<para>
@TODO
</para>
</chapter>
</part>
|
