Skip to content
z411 edited this page Feb 14, 2013 · 3 revisions

This is a small development guideline.

Design goals

  • Excel at managing local list offline and send/receive data over the network only when necessary
  • Highly configurable
  • Simple as possible; do what it's supposed to do and be good at it
  • Make it easy to implement new interfaces and new libraries to connect to different list management sites

Design Model

The program is designed in the following manner:

UI (GTK)    <-->        <-->              <--> Lib (libmelative) <-->
UI (curses) <--> Engine <--> Data Manager <--> Lib (libmal)      <--> Internet
UI (CLI)    <-->        <-->      |       <--> Lib (libvndb)     <-->
     v                            v
Acccount Man.                   Local DB
  1. The main script (bin/wmal*) launches the UI.
  2. The UI connects to a simple Account Manager (accountman.py) which reads and saves account information.
  3. The UI launches the Engine (engine.py) providing account information.
  4. The Engine asks the Data Manager to load the list.
  5. The Data Manager (data.py) decides if it should load a list from the Local DB, or ask the Lib (lib/lib*.py) to request information from the internet.
  6. Everything is saved in the Local DB and returns an OK to the Engine, which returns an OK to the UI.

After this, everything else requested by the UI is handled by the Engine. It will talk to the Data Manager if it needs information from it, and return the information to the UI. The Data Manager will do the same.

In other words, modules only talk to the module next to it. Do its thing, ask for information to the right if needed, reply to the left.

Coding a new UI or Lib

The advantage of the aforementioned design is that if you decide to code a new UI you just have to worry about talking to the Engine. At the same time, if you decide to code a new Lib, you just have to worry about replying to the Data Manager.

Documentation and examples will be uploaded once it's done.

Clone this wiki locally