model.py appears to be the model part of the model-view-controller pattern. I say appears as it does not quite fulfill the role of the model. If model.py were a proper model, I think adding support for Woodchuck would be much easier. Currently, I'm having to add code directly to the frontend, which seems inelegant.
The first limitation is that when the database is updated, it is the responsibility of the controller to update any views: model.py does not signal changes. Currently, the controller and the frontend are the same entity, so has not yet been a significant problem. Second, model.py assumes that there is only a single user. This manifests itself in how object lifetimes are managed: the frontend is required to manage cache coherency (e.g., model.py does not prevent the same object from being instantiated multiple times). Also, the DB model only exists implicitly: instead of instantiating a model with a DB, the DB need to be passed explicitly to routines, e.g., load_postcast. These problems make integrating Woodchuck unnecessarily invasive. Woodchuck needs to be able to snoop changes to the underlying data to be able to update the state on the Woodchuck server. Second, Woodchuck needs to be able to update streams and download objects. Currently, it can do so, but there is no way to signal the frontend that data has changed. If model.py were a proper model and Woodchuck a view, support for Woodchuck could largely be relegated to a single file. To this end, I'd like to propose that the Model class be made a proper class. The init function would then take a database as a parameter. get_podcasts (among others) would then be invoked against the instance and not the class and its DB parameter disappears. Likewise, PodcastChannels.load would not take a db. Instead, one would invoke Model.podcast_channels_load () (the same signature as PodcastChannels.load but without the db) to get a populated PodcastChannel instance. model.py would become responsible for managing object lifetimes. I propose that channels and episodes become singletons and that weak references be used to avoid having the whole DB in memory. Alternative, a shell class that contains just an object's key and a pointer to the real data could be used. model.py could forcefully destroy the real data and reduce memory use. This would reduce the impact of any reference leaks, a concern that Thomas raised on IRC. Finally, I propose that a new hook be added when a new model is instantiated. Woodchuck would use this to attach to the real database. I'm prepared to make these changes, however, before I do so, I'd like confirmation that this is the right approach. Thanks, Neal _______________________________________________ gpodder-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/gpodder-devel
