Home

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

Progress

The objective is to support all the features in every site, but development is still experimental so it's currently like this:

                       API support                Interface Support
----------------------------------------------  ----------------------
|            | MAL | AniDB | Melative | VNDB |  | CLI | curses | GTK |
----------------------------------------------  ----------------------
| Log-in     | Yes | Yes   | Yes      | Yes  |  | Yes | Yes    | Yes |
| Fetch list | Yes | No    | Yes      | Yes  |  | Yes | Yes    | Yes |
| Update     | Yes | No    | No       | Yes  |  | Yes | Yes    | Yes |
| Status     | Yes | No    | No       | Yes  |  | Yes | Yes    | Yes |
| Search/Add | Yes | No    | No       | Yes  |  | Yes | Yes    | Yes |
| Delete     | Yes | No    | No       | Yes  |  | Yes | Yes    | Yes |
| View info  | No  | No    | No       | No   |  | No  | No     | No  |
----------------------------------------------  ----------------------

The engine currently supports launching a media player and checking for already running players.

Supported mediatypes

The objective is to support every mediatype in each site, but for now this is what we have:

• MAL: Anime, Manga
• AniDB: N/A
• Melative: Anime, Manga, VNs, LNs
• VNDB: VNs

Why text interfaces?

Because

1. I like choice, and you should too!
2. I often watch anime without a mouse so a text interface is comfortable.
3. We Linux geeks love the terminal :-)