Hi, Thanks for replying in spite of being busy!

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.

Would you like to keep these attributes(those which are unused and we don't want to support) or should these be removed?

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.

From core's point of view this idea seems to be fine but I am unable to think of any way of representing this idea in Postorius(since new styles would be created there)? Earlier while discussing we decided to make style composable in terms of other styles(inheritance and fallback mechanism). For example, if a user wants to modify only the the autoresponses attributes of Style1, then, he may create a child style of Style1 and change only the attributes related to the autoresponses and rest of the attributes will take their values from the parent style(Style1). Also is there any advantage of making styles composable in terms of stylets?

...

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.

The new interface will contain only styleable attributes and not any immutable attributes like created_at. All the immutable attributes will reside in the existing 'IMailingList' interface. New interface(WIP): https://gitlab.com/_Harshit_/mailman/commit/6c94e220cd5f5ba857fa003bdc17919c...

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.

How will be the permissions enforced without authorization system?

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).

As I mentioned above that the new interface is going to have only styleable attributes.

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?

All attributes will be required only in case the style doesn't inherit from any other base style. In case the style inherits from some other base style then the dictionary(argument to the constructor) will contain only those attributes which the user wants to change and rest of the attributes would be taken from the parent style.

Also could you suggest some default value(such as 'DEFER') for styleable attributes that would trigger the fall back mechanism to take values from the parent style.

Thanks, Harshit Bansal.

Hi, Thanks for replying in spite of being busy!

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.

Would you like to keep these attributes(those which are unused and we don't want to support) or should these be removed?

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.

From core's point of view this idea seems to be fine but I am unable to think of any way of representing this idea in Postorius(since new styles would be created there)? Earlier while discussing we decided to make style composable in terms of other styles(inheritance and fallback mechanism). For example, if a user wants to modify only the the autoresponses attributes of Style1, then, he may create a child style of Style1 and change only the attributes related to the autoresponses and rest of the attributes will take their values from the parent style(Style1). Also is there any advantage of making styles composable in terms of stylets?

...

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.

The new interface will contain only styleable attributes and not any immutable attributes like created_at. All the immutable attributes will reside in the existing 'IMailingList' interface. New interface(WIP): https://gitlab.com/_Harshit_/mailman/commit/6c94e220cd5f5ba857fa003bdc17919c...

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.

How will be the permissions enforced without authorization system?

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).

As I mentioned above that the new interface is going to have only styleable attributes.

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?

All attributes will be required only in case the style doesn't inherit from any other base style. In case the style inherits from some other base style then the dictionary(argument to the constructor) will contain only those attributes which the user wants to change and rest of the attributes would be taken from the parent style.

Also could you suggest some default value(such as 'DEFER') for styleable attributes that would trigger the fall back mechanism to take values from the parent style.

Thanks, Harshit Bansal.