Here's a summary of a discussion that unfortunately got sparked offline, and belatedly is being moved to Mailman Developers. The basic point is that we need to assure that the structure of MM3 is such that it provides appropriate APIs through which proposed extensions could be added.
I am aware that the issue of API design bears on several of the proposals being considered for GSoC inclusion, so active contributions to collective wisdom would be very much appreciated!
N.B.: In reposting these comments, in the interest of brevity, where possible, I have deleted quotations contained in the replies.
On Apr 17, 2012, at 7:47 AM, Pierre-Yves Chibon wrote:
I am having some question about the NNTP, how will this co-exist with the archiver?
If I read this correctly, it will give access to the archives so that it can be used within a mail client. To do so, I will need to access the emails stored somewhere, but it is also my understanding that the emails are stored in the archiver.
Do we have duplication of information there? If so, shouldn't we build the email part of the archiver on the top of the NNTP bits? This would avoid having to stored the complete email archives on another system/ in another way. We could then just store, tags, categories and this sort of things only in the archiver, leaving the emails/threads part to be retrieved from the NNTP.
On Wed, Apr 18, 2012 at 6:24 AM, Richard Wackerbarth replied:
As I read the proposal, there are two possible uses for NNTP.
One would be as a list distribution mechanism providing delivery using the NNTP protocol in place of SMTP.
In a similar manner, we might have RSS feeds, etc.
The other use would be, as Pierre-Yves indicated, as a mechanism to retrieve messages from an archive.
And, on Apr 18, 2012, at 1:12 AM, Stephen J. Turnbull responded:
This is somewhat incoherent, as NNTP is inherently a pull mechanism
("store and serve" vs. SMTP's "store and forward"). Any "delivery"
that is done will be to an archive (by whatever name) that waits for
users to pull from it; it may as well provide interfaces for
conventional web access (ie as HTML pages), RSS/Atom feeds, NNTP, and
anything anybody dreams up (for example, a request-by-email
mechanism).
So I don't see how the implementation would end up being different from:
<retrieval from an archive>
Richard's thread continued:
If we are going down this path as a part of MM
Stephen interjected:
-1, except to the extent that we define APIs to the message store to be used by such modules.
rather than the archiver, then it might be appropriate to split the archiver into a "message store" and a UI to that store. In that context, an NNTP interface might provide an alternate UI.
Stephen responded:
That's precisely how I see this, and maildir will do for a start on
the message store. However, we need to hide the fact that we have a
maildir from the NNTP module and Hyperkitty etc. They just need to
know how to retrieve messages and summary results for list summary
screens (and maybe a search interface - NNTP doesn't need that, but
Hyperkitty will, and I can imagine IMAP etc wanting it).
An additional part of the thread contained:
On Apr 17, 2012, at 7:10 AM, Richard Wackerbarth wrote:
I do see some blurring between the MM core and other components.
For example, <...> seems to relate to accessing documents stored in the system. I view that as a function related to the archiver and not the core.
Similarly, going down the "user profile" road <...>, perhaps we should split out a "persona" component just as we have split out the archiver and the UI. This component would handle login/authentication, etc. as a service for both the core and for the UI. Personal profiles, could then be a plugin that "subscribes" to message events using a mechanism that could also drive archivers, NNTP feeds, etc.
In an analysis of how various components might be organized and interact within a defined structure, on Apr 17, 2012, at 4:24 PM, Richard Wackerbarth wrote:
In any case, we should assume that something of this nature <an alternate UI> will want to be "plugged in" in the (near?) future. As such, we need to provide a framework as a standard interface.
I view a plug-in as having four components:
- Some kind of information storage.
- An interface to the MM core. This would receive notifications of events, and might include the retreival and/or injection of messages.
- A configuration interface. This should modify the Protorious interface in much the same way as django models get registered and included in the django-admin.
- Custom user displays. These should integrate back into the django template structure so that a consistent, site-customized website presentation is available.
I think that we should be developing this framework NOW so that various GSoC projects, and others do not access information in an ad hoc manner.
To which, in his Apr 18, 2012, at 1:12 AM reply , Stephen J. Turnbull added:
+1 I like your analysis.
Agreed; I had already begun to feel that NNTP will have to coordinate with hyperkitty and any other archive UIs.
We now solicit additional observations, suggestions, and comments.
Richard & Stephen