Thanks for posting this Harshit. This is a useful discussion to have, and I have some thoughts, but first a little history.
In MM2.1, the MailList class is composed of a number of mixins, each of which implements a general chunk of functionality, such as NNTP or digests, etc. I really didn't like the mixin structure, so for MM3, I collapsed all the style attributes into a single IMailingList interface. As you've noticed, some of the attributes in the model class aren't described in the interface. Those are mostly the legacy attributes which should eventually go away (because they are unused or represent features we don't want to support), or converted to better database types (see the PickleType for accept_these_nonmembers). It's gotten a lot better, but there are still some holdovers from the old MM2.1 code, so more opportunities to clean up and modernize. I've always wanted styles to be composable, by which I mean that a style can describe just a partial set of attributes. For now I'll call these stylets. One stylet might define how autoresponses work, while another might describe how digests work. In a sense, this is analogous to how the composition was broken down in MM2.1, but without all the ugly mixin stuff. The current IStyles support this, but of course they are only applied to mailing lists when they are created, and changing a style does not change any list to which the style was applied. On Jun 01, 2016, at 11:47 PM, Harshit Bansal wrote: >I am thinking of adding a new interface named 'IStyleable' to the >mailman core. All the styleable attributes from the current >'IMailingList' interface will be moved to this new interface. The >current 'IMailingList' interface does not provide documentation for >all the styleable attributes. This new interface will contain all >styleable interfaces arranged in an orderly way with proper >documentation. This new interface then can be extended by the existing >'IMailingList' interface and the new 'IStyle' interface that I am >writing. I think this makes sense. You're refactoring out the interface for the attributes of a mailing list apart from the functionality that a list provides. There may be some attributes which aren't style related, e.g. created_at, and perhaps some that shouldn't get refactored because they identify the list (e.g. list_name and list_id), but we can discuss that. Once you have that refactored, then I think you need a way to say "this stylet sets attributes A, B, and C, but doesn't touch X, Y, and Z". That gives you back the composability without having to worry about partial interfaces; i.e. all IStylet (actual name TBD) interfaces *can* change any style attribute, but it's okay if they change only a subset. Then it may be possible to do a lot of cool things on stylets, such as impose permissions on changing or using one; recording the stylets used with a particular mailing list, so if you change the stylet, the mailing list automatically changes, etc. >Why I felt the need of a new interface? For constructing a new style I am >taking a dictionary as an input to the constructor which is supposed to >contain all the necessary styleable attributes and their corresponding values >as key value pairs and to check whether the dictionary contains all the >styleable attributes or not I will need to have a list of all the styleable >attributes and that can be done very easily if I have an interface >containning all the styleable attributes. I know there are other methods of >getting a list of all the attributes but they are neither pythonic nor stable >as all of them depend on python internals which are liable to change with the >version of python. Let me see if I understand: you want to query the IStyleable interface to know what attributes are allowed in a style. It makes sense in that case to use a separate interface just for that purpose, without cluttering it up with all the other interface bits specifically for mailing list operation (e.g. get_roster(), subscribe(), and immutable attributes like created_at and list_id). The only other comment on the above paragraph has to do with requiring a style to contain *all* the attributes. How would you handle the composability in that case? Cheers, -Barry _______________________________________________ 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