Hi, On Tuesday, February 21, 2012 14:59 CET, Richard Wackerbarth <rich...@nfsnet.org> wrote: > 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.
Yep, it obviously makes sense to separate data from business logic. And ideally the view code doesn't look (much) different whether it accesses a model stored in a db or a rest resource. (BTW, I recently started rewriting this part of the prototype in that sense.) But I'm not sure I would see database models as exactly equivalent to REST resources. > 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. Yep. But we need to decide how tolerant we are when it comes to inconsistencies between the state of the core data and a web ui session. A list of mailing lists might be stored on a per session basis - if a new list is created by a third party during a session, it's probably tolerable not to have that new list appear immediately. It's a bit trickier when it comes to privileges like moderation etc. that should probably take effect immediately (especially when revoked). > > 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. By that I meant: Something people installing it have to take care of by tweaking their settings.INSTALLED_APPS tuple. If it's part of the package, that doesn't need to be done. Although having an extra app for that could make sense if the different auth methods should be strictly pluggable. Cheers Florian _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org 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
