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@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@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%40s...
Security Policy: http://wiki.list.org/x/QIA9