[Mailman-Developers] GSoC 2015: brainstorming ideas suitable for beginners?

[Andrew Stuart]

>>>Do you think this has to be integrated into the core for 3.0?  I'd still prefer to keep it separate for better experimentation and testing. 

if:
 there was an “application data” table:

————————————————————————————————————————————————————————————————————————
resource_type  |  resource_id   |   private/public  |  key   |    value 
————————————————————————————————————————————————————————————————————————
user
list
domain
server

and:
 the ability to set domainowner and serverowner permissions in 3.0,

then:
 there would be a huge payoff in terms of avoiding the downstream challenge of migration upgrade scripts, data migrations, testing, backups, the risk of something going wrong for the end-user sysadmin. 

else:
 the alternative for me is to go ahead with deploying application data and domainowner and serverowner into the auth server, and later needing to work out how to migrate these back into Mailman core in some later version - I’m thinking that if those tables were there in Mailman 3.0 rather than say version 3.1 then a vast amount of downstream work, risk and thinking could be saved (for me). Not insurmountable but would really take alot of engineering to do safely. Getting random sysadmins to do stuff like data migrations that is a little anxiety provoking.

David Murray, who does the Python email package, implements APIs as “provisional” so they are not part of the official release but are present in the code, until some version further down the track where he formalises the provisional API following road testing and feedback.  Sort of a logical separation for experimentation and testing. Could that be a way to implement an application data table and serverowner and domainowner permissions in 3.0?  That way, consumers of the REST API can use the provisional API functionality at our own risk that it might change before being formalised. I’d take that any day over the need to write stuff that a random sysadmin could run to migrate their data into a new table structure later.

Implementing an application data table and domainowner/serverowner as “provisional” would be a stitch in time for me anyway.

As I mentioned I’ve done it myself anyway in the auth server but theres a bunch of unaddressed challenges relating to replication and synchronisation - whenever the application data is accessed, there needs to be checks to verify that both the user and the resource actually exist in Mailman, and there’s no easy way to know when users and resources have been deleted from Mailman, potentially leaving stale application data.

As always though, I’m not super attached to the outcomes - you’re the boss Barry so I’m OK with whatever path.

as




On 22 Feb 2015, at 5:05 am, Barry Warsaw <barry at list.org> wrote:

On Feb 20, 2015, at 07:25 PM, Andrew Stuart wrote:

> It’s workable as a part of the auth proxy but feels like it would fit better
> in the Mailman core database since the data is so tightly bound to Mailman
> resources.  It’ll need an effective replication mechanism to ensure
> consistency with Mailman which is a challenge I’m not relishing solving.

Do you think this has to be integrated into the core for 3.0?  I'd still
prefer to keep it separate for better experimentation and testing.  If the
design and API proves stable, then perhaps it'll make sense to integrate it
with the core for 3.1.

Cheers,
-Barry

_______________________________________________
Mailman-Developers mailing list
Mailman-Developers at 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/andrew.stuart%40supercoders.com.au

Security Policy: http://wiki.list.org/x/QIA9