[Mailman-Developers] GSoC Applicants

Stephen J. Turnbull stephen at xemacs.org
Tue May 7 04:04:37 CEST 2013


Shanu Salunke writes:

 > What I need help with as a starting point (at least) is how to "link" the
 > functionality with the (django) front-end. One solution (thank you abomard)
 > is using the API that (postorius also uses) MM3 and HK have support
 > for.

This isn't your job, IMO.

Your proposal is about integrating various functionality in a single
UI.  I agree that Django is a good implementation technology, because
the Postorius and HyperKitty applications use it.

How can integration be achieved?

Step 1.  Arms-length, proof-of-concept technology: use HTML frames to
    organize Postorius and HyperKitty connections along with any
    "native" "applets" you need (web-posting, mail-posting, NNTP
    posting and/or reading) in a single display.  Yes, frames suck for
    various reasons, but they're an easy way to impose organization
    without *any* cooperation from Postorius and HyperKitty.

    This step should go to the point of allowing you to conveniently
    *organize* multiple lists.  You probably won't be able to
    conveniently *manage* individual lists because of the
    "arms-length" nature of the technology.  Don't even try; move on
    to step 2.

Step 2.  All these apps are Django apps.  Django templates support
    inclusion and inheritance.  It should be possible to get better
    integration with template inclusion as a substitute for HTML
    frames.

Step 3.  Design an "API" for your templates, and propose changes to
    Postorius and HyperKitty templates to better integrate them into
    your app.

Step 4.  Design an API for your views that can cooperate with low-level
    REST APIs that Postorius and HyperKitty might export, to allow the
    various apps to reside on different servers.

Your Django models can probably be very simple, just a list nickname,
some identification (RFC 2919 List-Id), and a bunch of URLs (mail
posting, HyperKitty archives, Postorius subscriber and admin
interfaces, other functionality if any) in a single model.  That's not
a promise, of course, but I think you can start there.



More information about the Mailman-Developers mailing list