| 1 | -*- text -*- |
|---|
| 2 | |
|---|
| 3 | |
|---|
| 4 | Requirements |
|---|
| 5 | ============ |
|---|
| 6 | |
|---|
| 7 | 1) Persistence of registered events |
|---|
| 8 | 2) Minimal tracking of 'seen' and 'spoke' |
|---|
| 9 | 3) Library-user side flexibility to act on registered events |
|---|
| 10 | 4) If more than only (2): per user, per channel event tracking |
|---|
| 11 | |
|---|
| 12 | |
|---|
| 13 | Addressing the requirements |
|---|
| 14 | =========================== |
|---|
| 15 | |
|---|
| 16 | 1. Persistence is offered by the framework done by Xach. |
|---|
| 17 | |
|---|
| 18 | 2. Minimal tracking of 'seen' and 'spoke' is provided by the adapted |
|---|
| 19 | version of Xachs framework. |
|---|
| 20 | The current version is in so far unsatisfying that the client can't |
|---|
| 21 | choose the language of the messages shown to the user. |
|---|
| 22 | |
|---|
| 23 | 3. Library-user side flexibility to act on registered events |
|---|
| 24 | What I mean by that is that the client should be able to hook into |
|---|
| 25 | the mechanism which allows it to register |
|---|
