| 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
|
|---|
