Re: [Mailman-Developers] New Interface
Steve's got it right. Just a few other thoughts. On Jun 06, 2016, at 03:35 PM, Stephen J. Turnbull wrote: >(2) SQLAlchemy (and the underlying RDBMSes) allow you to have optional >fields. This is implemented by storing NULL in the missing field. I think we'd prefer this method, i.e. that the stylets would be stored in the existing database, and we'd use NULLs to indicate that a particular style variable is not set in the stylet. Thus, when that stylet is applied, it would just skip over that attribute. > > 3: If I go for style composabiltiy as described by you then how would > > I represent that idea in REST and Postorius? > >Basically the same way. Just sketching things out (IANAWD :) You'd be able to create new stylets, giving them a name. For each variable in a stylet you'd be able to say whether the variable is enabled or not. If it's not, then the stylet won't change that variable. If it is enabled then it can be set in that stylet. You probably want to be able to clone and delete stylets too. You'd then have a second interface which would be for composability. I think you should be able to select named stylets and include them in your style (which would also be named). You'd be able to reorder the stylets in a style, add and remove them from the stack, etc. Bonus would be to keep track of which styles and/or stylets apply to a particular list so you could do interesting things like: * find out which lists use(d) a particular style or stylet * change an existing mailing list by changing a style or stylet (which differs from how things work today. Of course styles and stylets would be exposed in REST, and we'd have to discuss where those resources live inside the tree. But we can do that later, once/if the basic model sketched out here and in Steve's response ends up making sense. 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
Re: [Mailman-Developers] New Interface
Harshit Bansal writes:
> How can this composability be achieved in a model? I mean that the
> size of a table is fixed in a model and if a style describes just a
> partial set of attributes then what would be stored in other
> attributes?
(1) In a NoSQL database (MongoDB, for example), you can store a
partial record with no preparation. This is a good thing and a
bad thing, depending on how the now-you-see-them-now-you-don't
fields are used.
(2) SQLAlchemy (and the underlying RDBMSes) allow you to have optional
fields. This is implemented by storing NULL in the missing field.
> Also how would this partial style be applied to a mailing list?
A style would be a list of stylets (NOTE! none of the identifiers
below are real! All names have been changed to protect my ignorance!):
s1 = { notmetoo_default: True, nomail_default: False }
s2 = { notmetoo_default: False, ack_default: True }
newstyle = [s1, s2]
def apply_style(style, mlist):
try:
mlist.start_transaction()
for s in style:
# common attributes will overwrite earlier values
mlist.apply_stylet(s)
# make sure all attributes are set to sane values
mlist.validate_style()
mlist.commit_transaction()
except Exception:
mlist.rollback_transaction()
> 2: Current 'IStyle' interface allows us to define either a partial
> style(stylet, describing just a partial set of attributes) or a
> complete style. But is that possible with a model?
There should be either an SQLAlchemy option for each attribute to be
optional, or maybe the inverse attribute of required. Use that option
on the model attributes.
> 3: If I go for style composabiltiy as described by you then how would
> I represent that idea in REST and Postorius?
Basically the same way.
___
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
Re: [Mailman-Developers] New Interface
Hi, On 04-Jun-2016 1:11 am, "Barry Warsaw" wrote: >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. How can this composability be achieved in a model? I mean that the size of a table is fixed in a model and if a style describes just a partial set of attributes then what would be stored in other attributes? Also how would this partial style be applied to a mailing list? Problems that are blocking me for past two-three days: Solved: 1: Getting a list of all styleable attributes. Since you have approved the new interface this problem is solved. Unsolved: 1: How to trigger the fallback mechanism? 2: Current 'IStyle' interface allows us to define either a partial style(stylet, describing just a partial set of attributes) or a complete style. But is that possible with a model? 3: If I go for style composabiltiy as described by you then how would I represent that idea in REST and Postorius? Thanks, Harshit Bansal ___ 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
Re: [Mailman-Developers] New Interface
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 ___ 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
Re: [Mailman-Developers] New Interface
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/6c94e220cd5f5ba857fa003bdc17919ca6f9217b > 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. ___ 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/archiv
Re: [Mailman-Developers] New Interface
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
[Mailman-Developers] New Interface
Hi, 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. 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. I had asked Barry for his comments but as he is busy in PyCon so he asked me to redirect my query to mailing list. As this was blocking so I in the meantime I wrote the new interface which can be found here: https://gitlab.com/_Harshit_/mailman/commit/6c94e220cd5f5ba857fa003bdc17919ca6f9217b Please provide your comments/suggestions on whether should I continue with this or not. Thanks, Harshit Bansal. ___ 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
