(If you can't tell, everything is fine!).This is just an idea for a extensible framework for the client that is hopefully easier to collaborate on (by multiple development teams). It is designed with the following in mind:
1) General framework that allows creation of new modules that introduce new behavior using a standard interface, and the adding of new UI "Views" of the same basic interface that can be managed by the framework.
2) Feature/Behavior abstraction into modules. Basically, each module is a complete subsystem with its own data and logic/behavior (controller). (Note: no UI here). A module can either be a "Data Module", which will include a manager to adds/manage some additional data (e.g. A module that allows you to associate image files on your hdd with a particular anime) or collect data from external/remote sources, or a "Service Module" (e.g. a module, often comes together with a View, that allows you to play mp3 file, view a image, launch a video file in an external player). Modules can also be dependent on other modules (e.g. An "Anime Image Album" module that lets you add and maintain a collection of images associated with an anime may be dependent on an "Anime Data Module" (to get the actual anime records to associate to) as well as an "Image Browser Module" (which includes a View to load and displays an image).
3) Abstract Presentation Layers, where each UI set (a "View") provides the user interface to interact with one or more depedent module. (Multiple views may interact with the same module, just as a View can collate interactions with several modules) There can be also alternative views for the same sort of data (e.g. one view that shows anime data in record rows, another that shows a short summary as well as cover art).
4) General Data Adaptors. Interfaces to all outside data through adaptors that transform source-specific data format to common internal data format. Each adaptor (and the team developing/maintaining it) is responsible only for the source that it supports (e.g. AniDB UDP versus AniDB HTTP). The people consuming the data don't have to care where it comes from as it is always supplied in some common format.
Of course, this is just a vision atm, but not really that far fetched.
Some points:
This is NOT another AOM
AOM is designed to be a local proxy to anidb. As such, it is both mirrors anidb better, but is also constrained by anidb structures/functionalities. This client design is meant to be general, though it can contain modules that support anidb specific functionalities.
One example: MyList can only be added on file basis. But sometimes I just want to catalog my collection, which can be on CD/DVD. There is no way to add a anime "logically" to mylist for easy reference, or to key in info like how many episodes I've watched and which episode I have collected (unless you add an actual file).
atm, AOM and this proposed project serves slightly different purposes, but with the modular framework, it IS possible to add in "AniDB" modules that will replicate most if not all the functions, though the underlying data will have to be reorganizes slightly to be representative rather than reflective of anidb's actual database.
Data Modules Description:
Each module is basically split into 3 parts roughly according to the MCV paradigm (data Model, Control logic, user interface (View) ). MCV is a little too idea in practical sense at times, but I find that abstracting the presentation (UI) away from control and data alone will already allow a much more flexible system. Think of the whole UI Views as "skins" that does not change the underlying capabilities and logic and you should get what I mean. It just renders data read from the module controllers so that user can see, and translate user interaction into actions/tasks to be passed to the controllers to be performed/processed.
Data (Model)
The "module specific data" refers to the actual data that the module maintains. It is assumed to be totally owned by the module (e.g. kept in a private subdirectory for the module where the contents are totally owned by the module). If the module is dependent on another module, the data could reference data in other modules (e.g. If I am creating a module that maintains an image album relating to an anime, it might keep a copy of the anime id). This is a loose coupling which may lost if some data is deleted or changed in the other module, so cross-module integrity will require slightly more work.
Controller (Control)
The "module controller" is the main control logic. It is stateless with regards to the actual data, but may keep its own config data. Usually, data and controller will be developed by same team. Also, each module will subscribe to, as well as publish a set of standard signals (same for all module) to hook it up to the application core.
UI (View)
These can be either created by the people who make the module or by 3rd party. Views will have to follow some standard interface class (e.g. Application Core may specify a ConfigView interface for creating a UI component that modifies preferences and user states for the module, while a DataView interface will specify the standards for a UI component that displays certain data in the model). The proper abstraction of UI away from the controller and data means that : if somebody don't like the current UI, he can always replace it with a custom one (or even one he designs) yet keeping the controller/data unaffected. A View can be dependent on solely one module, or can depend on multiple modules if it collates features from different modules (e.g. say I want to view and compare ratings from 5 different online anime databases). Or it can even be dependent on none (say I have a dummy view that shows a clock??? ok ok... maybe it is still dependent on some system module since it needs to get time, unless it is done hackily through direct reading of OS time)
Possible Example:
Suppose I want to create a module that maintains a collection of images for each anime.
The data part will maybe consist of the creation of an image folder and a lookup table. When an image is "added", it will be copied to this folder and an entry created in the table indicating which is the associated anime.
The module controller part will of course be the part that handles the actual association/disassociation of images, as well as maintenance stuff like copying new images into the repository or deleting unwanted images. The controller will have a standard interface that interacts with the application code, but will also sport a module-specific interface which is only seen by its UI submodules or other dependent modules. The controller will probably be dependent on some other system modules in order to create/rename/delete files/directories and load/save image files.
A ConfigView can be created to allow the user to do things like setting whether the image should be copied/moved into repository when adding or just have a soft-link added without moving the original image. Other options may be whether to generate thumbnails etc). This will be automatically displayed as a tab when user chooses to launch the "preference" dialog. For the DataView, one possible (and obvious) one will be to display one image, maybe with some zooming/slideshow controls. Another DataView could show all the images as thumbnails, with commands to add/remove images. When enabled, a DataView can be shown as a tab or child window in the main content area.
Possible Modules:
Core Module (must have)
Core anime module that stores the non-volatile, standard factual information about an anime such as:
anime info
+-titles
+-episodes
+-genre
+-ratings sets
+-last updated
episode info
+-summary
company info
character info
+-description
+-voice actor info
Core module is also the main module that will try to keep things updated, or drive searches on remote servers. It should also allow user to overwrite change things for local view.
Anime Collection Module
This module is meant to keep track of a user's anime collection be it on harddisk, cd or dvd. It can have options like recording which are the episodes collected as well as which are watched. Extended "library" functions may even keep track of things like whether it is loaned to a friend (if on CD/DVD) or contain a link to a local file (if it is on HDD). It will also allow the user to key in his custom ratings (as opposed to collated ratings from anidb) or append additional notes or resource associations.
Image Album Module
already described above as example.
SoundTrack Module
Catalogs the released albums/tacks/art/lyrics data related to an anime. Provide links to local mp3 files if specified by user (maybe include a module that plays it within the app?). May even interface with external players like winamp or itunes or whatever. If dependent on some existing "media-player module", may even play the track within the app.
<Use your imagination and post your dream module here!!!>
these are just some ideas I can think of off my head. Notes are a little messy as i didn't spend a lot of time on it. It is just a matter of pumping in organization/design and hard labor.
atm, these are just ideas to test response. I do have intention to develop it, but may lack the time and motivation on my own
So just treat it as pass-time reading for now. If there are any comments (positive or negative are both welcomed, as long as it is constructive!) or ideas, do add on.lastly, a diagram that shows how development can be organized so that more people can work in parallel...
