On Jun 04, 2016, at 07:38 PM, Harshit Bansal wrote:

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

For now, keep them. It would probably make sense to open an issue on gitlab listing the unused attributes to delete. We can mark that as a tech-debt issue and address it outside of the context of your work.

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

Yes, the ui issues are challenging. ;) I think it would be fairly easy to represent in REST.

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?

It allows the admin to only be concerned with the attributes defined in the stylet. It can be fairly difficult otherwise to figure out what a specific stylet modifies.

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.

Cool.

...

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?

Postorius would enforce it for now. When we have the authproxy, it will do it for scripts.

...

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.

That's tricky. If we weren't interfacing to a database (i.e. in pure Python), we'd have a marker object, e.g. INHERIT = object() but we have to worry about database column types. I'm not sure what the right thing to do there is.

-Barry