Prakhar Joshi DA-IICT,Gandhinagar

On Sat, Mar 21, 2015 at 4:53 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

prakhar joshi writes:

...

So you want to store only changed attributes under a specific list style in the table ? Isn't that make the table dynamic in width as sometimes only one attribute is stored and sometimes 3-4 attributes are stored ?

That's a feature of object-relational managers (ORM) like SQLAlchemy. In the background there will be a special value in the backing RDBMS such as 'inherit' or perhaps NULL. But NULL is risky because it has assorted interpretations.

Yeah we will put values in the backing of RDBMS like the default values and not NULL.

...

By extensibility you mean to add new attributes ?

Attributes.

See we have a lot of attributes in mailing list table so admin can create extra attribute other than those or admin will just play with the present attributes in mailman3 mailinglist table. (I am considering the later one)

...

or add new class as there are few classes in the mailman/src/mailma/styles/base.py (but that can't be possible through web interface, I guess? )

Anything's possible, but Zope's experience with that level of through-the-web extensibility was pretty bad. We don't need it.

...

...

{ name: <list specific>, read-only: no, notmetoo_default: no } { name: anonymous_overlay, read-only: yes, redact_all_addresses: yes } { name: discussion, read-only: yes, <usual discussion list options ...> }

If there are more than 1 attributes in the last section of above list style configuration then the list table will not have the same width ?

I'm not sure what you're asking. Tables have to have the same width by definition. You use NULLs or other special values to simulate absence of a value, or a table join with optional attributes in a separate table. Object-oriented DBs can have different attributes for each object.

Yeah we will add other special values(like the default values) to simulate the absence of a value in style table.

...

unspecified attributes ? You mean attributes other than that of mailing list table ?

No, I mean the attributes I was too lazy to write in the schematic example above.

...

I think we are still not on same page for list style storage as still there are few things that I have in my mind like admin can't create its own new attribute, he/she can just change the value of the attribute, right ?

Probably. What I had in mind was that site admins could add new Handlers that define attributes that aren't in the standard set, or somebody could want to import a style from a later version of Mailman that has such attributes.

See we have all the attributes in mailinglist table for list settings and in the Handler we pick some set of attributes which are in mailing list table and combine these attributes in a style name. right ? So that if admin applied that style then the attributes set in that style will be overwritten in the mailinglist table, Am I right ?

...

And if that is true(admin can't add new attributes) than how can we just store only changed/modified attributes in the styles table as than the table will not have same width, lets assume for style A we will store one attributes and for style B we will store two/more attribute.

To create attributes on the fly is easy, even in RDBMS. You have a table user_defined_attributes with columns foreign_key, attribute_id, and attribute_value. Then do a select on the foreign key.

...

Basically the style table will be copy of mailing list table and will have same number of column same as mailing list table with one more column about permission (read_only or editable).

You need to be more careful about this. I'm not sure exactly how this is implemented in Mailman 3, but a mailing list has attributes (such as the owner and the moderator list) that are not relevant to styles. There is going to be a question of whether to refactor the list schema into a "stylable" part and a "list-specific" part (so that the stylable part is literally a copy of the style) or to copy the individual attributes from styles to the list configuration.

In mailman3 the mailinglist table contains all the attribute so we will copy only those attributes in the style table that are related to styles(settings ) of the list only. Yeah I should have mentioned that before.

Basically I was trying to store a style directly with its name, permission and attributes like "reply to address","send welcome message" (Admin will define values of these attributes and rest will have default values in the style table) and when a style is applied to any list than these attributes will be overwritten on the mailing list table from style table. This is the way I was trying to store the style ( a very basic model for storing styles) Now we will have the generic way to copy the attributes from a particular style to the mailing list. I hope I am clear this time ?

I will explain my way of storing with an example. Lets assume we have a mailing list named "XYZ" and it is stored in the mailing list table and as we have all the attributes in mailing list table so some default values will be set to all these attributes(as mentioned in mailman/src/mailman/model/mailinglist.py) for the list "XYZ". Now if a admin comes and create a style named "foo" so we will provide all the attribute(by all attributes I mean the attributes in the mailinglist table related to settings) to that admin with default values and now admin will change few values and rest values will be as it is and admin hits the submit button and provide an option of editable on that style(foo). Now "foo" will be stored in the table with style name (foo), user_id, permissions(editable) and all the attributes with their value set by that admin.

Now if the admin applies this "foo" to a list("XYZ") then the values of attributes from style table of "foo" will be overwritten in the mailing list table of the list named "XYZ". So this way a style can be applied to a list ("XYZ").

Now if other admin want to use that style("foo") he/she can also apply it to their list (some other name, maybe "ABC") the other admin cannot edit those style values as he/she is not the owner of that style. Style creators can only edit their style and other admin can user them(if they wish).

This is what I am proposing for implementing the styles to the list. Here admin can create new style, use them, edit them(only their styles), store them and implement them to the mailing list.

Thanks,

Prakhar Joshi DA-IICT,Gandhinagar

On Sat, Mar 21, 2015 at 4:53 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

prakhar joshi writes:

...

So you want to store only changed attributes under a specific list style in the table ? Isn't that make the table dynamic in width as sometimes only one attribute is stored and sometimes 3-4 attributes are stored ?

That's a feature of object-relational managers (ORM) like SQLAlchemy. In the background there will be a special value in the backing RDBMS such as 'inherit' or perhaps NULL. But NULL is risky because it has assorted interpretations.

Yeah we will put values in the backing of RDBMS like the default values and not NULL.

...

By extensibility you mean to add new attributes ?

Attributes.

See we have a lot of attributes in mailing list table so admin can create extra attribute other than those or admin will just play with the present attributes in mailman3 mailinglist table. (I am considering the later one)

...

or add new class as there are few classes in the mailman/src/mailma/styles/base.py (but that can't be possible through web interface, I guess? )

Anything's possible, but Zope's experience with that level of through-the-web extensibility was pretty bad. We don't need it.

...

...

{ name: <list specific>, read-only: no, notmetoo_default: no } { name: anonymous_overlay, read-only: yes, redact_all_addresses: yes } { name: discussion, read-only: yes, <usual discussion list options ...> }

If there are more than 1 attributes in the last section of above list style configuration then the list table will not have the same width ?

I'm not sure what you're asking. Tables have to have the same width by definition. You use NULLs or other special values to simulate absence of a value, or a table join with optional attributes in a separate table. Object-oriented DBs can have different attributes for each object.

Yeah we will add other special values(like the default values) to simulate the absence of a value in style table.

...

unspecified attributes ? You mean attributes other than that of mailing list table ?

No, I mean the attributes I was too lazy to write in the schematic example above.

...

I think we are still not on same page for list style storage as still there are few things that I have in my mind like admin can't create its own new attribute, he/she can just change the value of the attribute, right ?

Probably. What I had in mind was that site admins could add new Handlers that define attributes that aren't in the standard set, or somebody could want to import a style from a later version of Mailman that has such attributes.

See we have all the attributes in mailinglist table for list settings and in the Handler we pick some set of attributes which are in mailing list table and combine these attributes in a style name. right ? So that if admin applied that style then the attributes set in that style will be overwritten in the mailinglist table, Am I right ?

...

And if that is true(admin can't add new attributes) than how can we just store only changed/modified attributes in the styles table as than the table will not have same width, lets assume for style A we will store one attributes and for style B we will store two/more attribute.

To create attributes on the fly is easy, even in RDBMS. You have a table user_defined_attributes with columns foreign_key, attribute_id, and attribute_value. Then do a select on the foreign key.

...

Basically the style table will be copy of mailing list table and will have same number of column same as mailing list table with one more column about permission (read_only or editable).

You need to be more careful about this. I'm not sure exactly how this is implemented in Mailman 3, but a mailing list has attributes (such as the owner and the moderator list) that are not relevant to styles. There is going to be a question of whether to refactor the list schema into a "stylable" part and a "list-specific" part (so that the stylable part is literally a copy of the style) or to copy the individual attributes from styles to the list configuration.

In mailman3 the mailinglist table contains all the attribute so we will copy only those attributes in the style table that are related to styles(settings ) of the list only. Yeah I should have mentioned that before.

Basically I was trying to store a style directly with its name, permission and attributes like "reply to address","send welcome message" (Admin will define values of these attributes and rest will have default values in the style table) and when a style is applied to any list than these attributes will be overwritten on the mailing list table from style table. This is the way I was trying to store the style ( a very basic model for storing styles) Now we will have the generic way to copy the attributes from a particular style to the mailing list. I hope I am clear this time ?

I will explain my way of storing with an example. Lets assume we have a mailing list named "XYZ" and it is stored in the mailing list table and as we have all the attributes in mailing list table so some default values will be set to all these attributes(as mentioned in mailman/src/mailman/model/mailinglist.py) for the list "XYZ". Now if a admin comes and create a style named "foo" so we will provide all the attribute(by all attributes I mean the attributes in the mailinglist table related to settings) to that admin with default values and now admin will change few values and rest values will be as it is and admin hits the submit button and provide an option of editable on that style(foo). Now "foo" will be stored in the table with style name (foo), user_id, permissions(editable) and all the attributes with their value set by that admin.

Now if the admin applies this "foo" to a list("XYZ") then the values of attributes from style table of "foo" will be overwritten in the mailing list table of the list named "XYZ". So this way a style can be applied to a list ("XYZ").

Now if other admin want to use that style("foo") he/she can also apply it to their list (some other name, maybe "ABC") the other admin cannot edit those style values as he/she is not the owner of that style. Style creators can only edit their style and other admin can user them(if they wish).

This is what I am proposing for implementing the styles to the list. Here admin can create new style, use them, edit them(only their styles), store them and implement them to the mailing list.

Thanks,