[Mailman3-dev] Mailing list attributes: immediate access, or proxied?

[Kapil Thangavelu]

On Mar 29, 2005, at 3:28 PM, J C Lawrence wrote:

> On Tue, 29 Mar 2005 09:58:47 -0500
> Mark Bucciarelli <mark at gaiahost.coop> wrote:
>
>> I see your point.  The list attributes are pulled from a SQL table, so
>> it's possible that someone could add a custom attribute (to the table)
>> and then a later release of mailman could add a new class attribute
>> with that name.  That could lead to some amazing bug.
>
> Having spent the last week looking at just such bugs, yeah.
>
>> But this is the only scenario I could think of; i.e. where a user adds
>> a custom attribute.
>
> Users are going to want to do that.  They are going to want to 
> implement
> custom schema with attributes which are then reflected at the SMTP
> layer, in the web UI, etc etc.  They are going to want to do this
> arbitrarily, and they are going to expect that their code will work
> across multiple Mailman version releases.  They are going to want to be
> able to be Mailman experts.
>
> We should support that.
>

agreed, i think all of this falls out a whole lot more simply with 
interfaces and schemas rather then dictating implementation items like 
__getattr__ hooks and proxies.

ie define the core schema for mailman operations on a list and others 
can extend as needed for their custom attributes and serialization.
as you say, newstyle class properties offer the flexibility of 
attribute access with arbitrary impl. additionally it would be nicer if 
we can break down the core schema to its component parts, ie mailman 
list transport schema vs. mailman list web schema, or use adaptation 
where possible.

  i'm curious what got done at the sprint, is there a summary available 
anywhere?

cheers,

-kapil