canmove, Confirmed users
1,570
edits
| Line 63: | Line 63: | ||
If we were to go the route of using sqlite templates to build the UI then it would be necessary to fill the database with all of the generated properties that are currently available on the EM rdf datasource as well as keep them up to date when things like the locale and preferences are changed in the application. | If we were to go the route of using sqlite templates to build the UI then it would be necessary to fill the database with all of the generated properties that are currently available on the EM rdf datasource as well as keep them up to date when things like the locale and preferences are changed in the application. | ||
I don't believe that this is the sensible route to take. However instead | I don't believe that this is the sensible route to take. However instead this essentially requires that a new API be provided such that the UI can get the lists of installed add-ons and that contains methods to get those generated properties when necessary. | ||
==Database Schema== | |||
The database then should only contain the fixed information about installed add-ons, essentially all of the data read from the install.rdf, as well as any information needed to persist restarts like available update information. | The database then should only contain the fixed information about installed add-ons, essentially all of the data read from the install.rdf, as well as any information needed to persist restarts like available update information. | ||
This means that information about add-ons waiting to be installed and downloaded no longer need to be in the database. They can instead be held in in-memory data structures. | This means that information about add-ons waiting to be installed and downloaded no longer need to be in the database. They can instead be held in in-memory data structures. | ||
The database will look roughly like this: | The database will look roughly like this: | ||