This repository has been archived by the owner on Jul 30, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1
/
DESIGN
56 lines (32 loc) · 3.17 KB
/
DESIGN
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
# Mieli's design
## Core values
- We love the command line: admin tools must have always a CLI counterpart even if Django admin can be used.
- Keep it simple.
- Keep Django as it is: don't customize it.
- First, security. Second, convention. Third, beauty.
- Modularize all the things!
- Good code explains itself but awesome code has comments when needed.
- Numeric ids are for foreign keys, not URLs.
- (Almost) 100% test coverage or die.
## Bussiness
### Organizations
Organizations are nexus. Groups are nexus. What is a nexus? [Check it out](http://lyd.dario.im/nexus). Previous concepts are specific roles for nexus. Just to keep it simple, they will be different classes and groups will be called nexus, so they don't clash with Django Group model.
One organization has a site under one domain. Organizations can be grouped under meta-organizations, where user identifies as <user>@<domain>.
Organizations are composed by one or more nexus. Nexus can be hierarchical (with optional members "composition").
Default nexus are:
- Administrators: somebody who manages/owns/coordinates the organization.
Every organization must be treated as external. Don't assume they may be hosted in the same instance.
## Technical
### Process architecture
Python can be a memory hog. As Mieli will become a core tool for liquid organizations, it must be cheap to deploy.
We don't want to develop it in Go, in order to allow more people to contribute, Mieli will work as a single process, with no limit for auxiliary processes (cache, database, queues, etc) neither for setting it up as a pool of workers (clone processes) for horizontal scaling.
Therefore we must take into account this in Mieli's features.
### Multiple sites
Mieli must support multiples sites, keeping them under a single process (or group of processes) but internally separated.
Django support sites with SITE_ID mechanism but it doesn't relate properly with User model. Also, we want to keep sites apart from each other: no sharing users, privileges or any other info. If we follow a "you have one user per instance" policy under a multisite setup, a malicious admin could log in a different site on the same system just changing a user's password associated to both.
At this point, we need a way to use Django's standard User model without customizing it. The "Simple Way" (TM) is to concatenate site's domain to the login name sent by the user.
In this way, organizations can freely assign usernames with custom policies and it even opens up federation in a easy way.
### Hooks and filters
Mieli must allow proper extension through addition of functionality (events and hooks) and modification of parameters (filters). This is a simple way to loosely couple our modules. No hard dependencies, just events and filters.
Hooks allow to react on specific events signaled by other modules and apps. Hooks should be able to choose if they are sync or async (through task queues). Events are not predefined, just raised from where we want but hooks must be registered at your app's mli.py file (like Django's admin.py).
Filters are like hooks but they can modify arguments. They must return all the arguments. They are useful to add additional flags in CLI tools.