On Apr 11, 2013, at 07:02 PM, Richard Wackerbarth wrote:
I encourage any GSoC candidates to actively discuss design issues on this list. Many aspects of MM3 remain only partially defined and still require design in addition to the coding that will follow. Although some might expect the mentors might "spoon feed" coding tasks, as a mentor, I would prefer to work with someone who is actively involved in the design as well as the implementation.
Totally agree.
First, there are some parameters that do not relate to any particular mailing list. IMHO, these aspects need not even be addressed in a conversion. If I wish to set up a MM3 installation, I should first, manually, set up a sample list. After I do so, the configuration of any "real" lists needs to be COMPLETELY configurable using the REST interface. If that interface is not presently adequate, it needs to be revised rather than "working around" any deficiency.
The REST API is pretty easy to extend. By far the most time consuming bit (assuming you know where you want your resources to live) is writing docs and tests. For many of the GSoC tasks, extending the REST API should be considered part of the work. This of course includes both in the core and in the mailman-client wrapper.
Therefore, I should be able to set up my "sample list" and, thereafter, add/edit all of the real lists utilizing the same interface (using mailman.cliient, etc.) that is available to the Postorius interface for list creation/editing. A migration tool would, therefore, need only "simulate" those manual steps that the installer would execute on a web-based interface to create a new list and adjust its settings.
Perhaps. I think migrations could be done this way, but it's probably more efficient to do it against the internal API.
Similarly, handling the subscriptions must be something that can be done using just the access exposed via the REST interface.
The big distinction between MM2 and MM3 lies in the conceptual model of entities. In MM2, each subscription is a separate entity. In MM3, subscriptions belong to "persons" and management functions are made available for the person to affect multiple subscriptions at the same time.
In translating from MM2 to MM3, the aggregation of subscriptions under a common "person" becomes a non-trivial task. However the mechanisms required to handle reassignment are needed within MM3 implementations because there is an alternate access mechanism (admin by email) which cannot directly identify these "persons".
Absolutely right. It's an open question as to how to merge user records. Because the user "databases" in a multi-list MM2 site are silos, there's no connection between my settings in listA and my settings in listB. How would you combine those into a single user record for MM3?
Additionally, in MM2 you don't now that me1@example.com and me2@example.com are both owned by me. While it's probably impossible to merge these two records when migrating them to MM3, we would like to have *some* way to merge the two records once they're migrated to MM3. We'd need to work out the workflow for that, including any security guarantees, so that a user could merge those records after a migration.
Therefore, I would suggest that a migration be broken into some components,
- Migrate individual list parameters
- Aggregate groups of lists
- Migrate individual subscriptions
- Aggregate subscriptions by "person".
-Barry