Andrew Stuart writes: > So there is something to be said for a very simple Mailman Core > key/value store mechanism that would meet some simple needs. The > argument against this is “well you’re going to outgrow it pretty > quick anyway so why not immediately start with a more full featured > data store”.
I don't think you're going to outgrow it. We have a sufficiently flexible way to name resources (URI is a proof of concept) and accesses, so a permission is just a triple (add a user). One problem we face is secure communication between components for identification and authentication purposes, which currently isn't present in Mailman at all. *That* could be a real problem, as there may be embedded design decisions that induce a conflict between efficiency and security (I don't think so, but that's the kind of problem one typically runs into). We also need an authorization scheme which doesn't propagate excessive privilege across components, but that can be done in principle by making permissions into quadruples (add the component to distinguish privileges in one component from privileges in another). This kind of thing has been done for a long time (Kerberos), so I guess the question is do we really need Kerberos, or can we get away with something a lot less complex? Finally we need the discipline to design and consistently implement a system-wide authorization system. That's undoubtedly the hardest part. Steve _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9