diff options
-rw-r--r-- | docs/design.md | 15 | ||||
-rw-r--r-- | docs/requirements.md | 8 |
2 files changed, 19 insertions, 4 deletions
diff --git a/docs/design.md b/docs/design.md index aff49183..5d6d0754 100644 --- a/docs/design.md +++ b/docs/design.md | |||
@@ -9,7 +9,7 @@ The overall architecture is split into three layers; Ui, Domain Logic and Infras | |||
9 | 9 | ||
10 | ``` | 10 | ``` |
11 | +----------------------------+ | 11 | +----------------------------+ |
12 | | UI | | 12 | | UI / Application | |
13 | +----------------------------+ | 13 | +----------------------------+ |
14 | | | | 14 | | | |
15 | | Domain Logic | | 15 | | Domain Logic | |
@@ -33,6 +33,19 @@ The infrastructure layer provides: | |||
33 | Various bits of the infrastructure layer may be exchanged on different platforms, to i.e. integrate into native infrastructure providers on a platform. | 33 | Various bits of the infrastructure layer may be exchanged on different platforms, to i.e. integrate into native infrastructure providers on a platform. |
34 | 34 | ||
35 | Note: By using the onion architecture we ensure the infrastructure is exchangable just as well as the UI. | 35 | Note: By using the onion architecture we ensure the infrastructure is exchangable just as well as the UI. |
36 | Note: The domain objects might also be specified in Akonadi Next. | ||
37 | |||
38 | ## UI / Application | ||
39 | The UI / Application layer contains all the views, and their composition, that make up the application. | ||
40 | All the interactions between the different components are defined here. | ||
41 | |||
42 | ### UI Component Interaction | ||
43 | UI components will have to be able to: | ||
44 | |||
45 | * Load certain views directly inline (e.g. load a calendar into a mail with an invitation, or a maileditor into the maillist) | ||
46 | * Change the overall application state by i.e. triggering the calendar to show a certain date-range. | ||
47 | |||
48 | This is ideally decoupled in a way that the provider of such a service can be replaced without changing the users of the service. Additionally it should be possible for external applications (such as a plasmoid), to load the same views, possibly through the same mechanism. | ||
36 | 49 | ||
37 | ## Domain Logic | 50 | ## Domain Logic |
38 | 51 | ||
diff --git a/docs/requirements.md b/docs/requirements.md index a3a72b4a..c6b89e5c 100644 --- a/docs/requirements.md +++ b/docs/requirements.md | |||
@@ -87,7 +87,6 @@ Currently available dependencies: | |||
87 | * Run the tests before you push | 87 | * Run the tests before you push |
88 | 88 | ||
89 | # Roadmap | 89 | # Roadmap |
90 | |||
91 | The final roadmap lives on phabricator.kde.org. This section tries to outline some of the high level aims that should help form the roadmap. | 90 | The final roadmap lives on phabricator.kde.org. This section tries to outline some of the high level aims that should help form the roadmap. |
92 | 91 | ||
93 | ## Priorities | 92 | ## Priorities |
@@ -118,7 +117,6 @@ The final roadmap lives on phabricator.kde.org. This section tries to outline so | |||
118 | * Offline support | 117 | * Offline support |
119 | 118 | ||
120 | ## Features | 119 | ## Features |
121 | |||
122 | A list of features that has to be refined and put on the roadmap on phabricator. | 120 | A list of features that has to be refined and put on the roadmap on phabricator. |
123 | This is very much WIP and the features listed here are largely coming from what is existing in Kontact and the Kolab Groupware Server. | 121 | This is very much WIP and the features listed here are largely coming from what is existing in Kontact and the Kolab Groupware Server. |
124 | 122 | ||
@@ -192,6 +190,11 @@ This is very much WIP and the features listed here are largely coming from what | |||
192 | * Quick inline reply in mails (what's app style) | 190 | * Quick inline reply in mails (what's app style) |
193 | * Note taking/todo management on the run, with categorization workflow on the desktop (or also on mobile) | 191 | * Note taking/todo management on the run, with categorization workflow on the desktop (or also on mobile) |
194 | 192 | ||
193 | ## Platforms | ||
194 | Desktop linux is the primary platform that we'll pursue first, because it's the easist target. As soon as we have a viable proof of concept and the architecture is set, Windows and OS X will follow, so we ensure early on that the project works on all platforms. | ||
195 | |||
196 | Android will be tried in the form of a research project, and depending on the difficulties we face the situation will be reevaluated. | ||
197 | |||
195 | # Deliverables | 198 | # Deliverables |
196 | These are the high-level aims that we have to work towards. This list is not a final list of deliverables, but should convey the areas we need to work on. More detailed information should eventually be available on phabricator. | 199 | These are the high-level aims that we have to work towards. This list is not a final list of deliverables, but should convey the areas we need to work on. More detailed information should eventually be available on phabricator. |
197 | 200 | ||
@@ -218,4 +221,3 @@ These are the high-level aims that we have to work towards. This list is not a f | |||
218 | * Functional blocks: We need to identify the function blocks that we require, see to what extent they are already existing and how we can reuse what's there already. The functinal blocks should largely follow from the identified requirements. | 221 | * Functional blocks: We need to identify the function blocks that we require, see to what extent they are already existing and how we can reuse what's there already. The functinal blocks should largely follow from the identified requirements. |
219 | * Prototype the domain logic: We need to prototype the domain logic as envisioned to see wether that works out. This will be an ongoing process especially while working towards the first milestone. | 222 | * Prototype the domain logic: We need to prototype the domain logic as envisioned to see wether that works out. This will be an ongoing process especially while working towards the first milestone. |
220 | * Prototype with domain logic + akonadi next + trivial UI. Show that this can work in it's basics. | 223 | * Prototype with domain logic + akonadi next + trivial UI. Show that this can work in it's basics. |
221 | |||