On Feb 20, 2012, at 7:00 PM, Florian Fuchs wrote: > Agreed. Django's User model <snip>
> OTOH it could make great sense to enhance this data with all kinds of crazy > things that could be stored in the web ui. Or to store some user data > temporarily to reduce API calls. But this means we'd have two different data > sources since the web ui should not access the core db directly. Let me suggest that we "step back" a bit from the implementation and look at the infrastructure architecture. The Web UI is a Django site. Therefore, (IMHO), we should build it as one. That means that we have some django apps that represent the MM functionality. They have models and views just like any other django site. The models for the users, lists, etc. just "happen" to represent the same data structure as that used by the MM core. The database access becomes a stack. The UI always accesses its data through its model. The implementation of the access could be directly as a table on a local database (as django is normally used) or it could use the REST interface to utilize the MM core as its data store. I would also introduce a transparent caching layer which would be optional. I suspect that (almost all of) the part of the MM database that is accessed by the UI could be classified as "read mostly" and that we could cache the information on a per-session basis, thus avoiding many of the accesses thru the REST interface. > Of course, if we implement such a custom backend we should do it in a generic > and reusable way. I just think making a full-blown django app for what is > usually just a .py file might be a bit overkill... But as I said: > debatable... ;-) I'm not sure what you mean by "full-blown django app". Even though an app must have models, views, templates, etc., those can usually be empty placeholder files. > I guess in the end it's not a question of whether or not we make use of the > Django User model. (At least to me) the question is: Do we use it to store > user data permamently in the web ui or just temporarily on a request/session > basis. Or a mix of both. We will definitely need some persistent storage that is beyond the functionality provided by the current MM core. Whether that storage is provided locally by a UI-owned database or the core database is extended to provide the backing store should be configurable at a later time. Another approach would be to migrate all of the storage to a separate module and let both the UI and the "core" interface to it. The REST interface could also be layered on top of it to provide an alternate API that could be bypassed by the core and/or the UI. This would make provide a clean place to insert "foreign" databases as might be maintained by existing enterprise infrastructures. Richard Richard _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
