Hi list !
A few weeks ago, I showed interest in participating to mod_mbox
development. As a proof of my will to become part of "the team", I've
already made two interesting improvements to actual module code :
- Email obfuscation (patch submitted last week to this list)
- A brand new XML+XSLT based interface, currently using client side
XSLT processing.
Both of them are in action on my local mod_mbox setup :
http://skikda.bulix.org/archives/
But for now, I'd like to speak and start to discuss about mod_mbox
future, and -to be a bit more accurate- to what I might do as my SoC
summer project.
Please note that whether or not I'm accepted into this program, I'm
willing to work on mod_mbox for the same reasons I claimed at the
beginning of my SoC application (available at
http://blog.bulix.org/index.php/pages/googlesoc/show).
There are two main points that currently come to me that need to be
discussed since it involves mod_mbox basis design.
* XSLT processing
As far as I remember, the choice of outputting XML satisfies
everybody. The problem relates to where we'll do the XSLT
processing. There are two main solutions :
- client-side processing, as by now. The user requires a capable
browser such as Gecko-based browsers.
- server-side processing, using mod_transform (or something else,
ideas ? I don't know much about server-side output filters)
Client-side processing's advantage is to fasten global response time
since the server have less work to do. Main drawback is the lack of
XSLT-capable browser (even KHTML doesn't seem to do it).
Server-side processing corrects this problem, but may slow down the
response (isn't mod_mbox designed to be as quick as possible ?).
* A mailing-list management application ?
It has been said recently on this list that you (as in developers
involved in mod_mbox development) wish to make mod_mbox become a
full-featured mailing-list management complete application, that can
handle multiple mailing lists, and especially from a row rsync
checkout.
I completely agree with this last point (rsync), but I must say that I
have some doubts about the first one (making mod_mbox a complete
management application).
Indeed, making mod_mbox a application that can manage multiple lists
correctly (e.g. with additional list information better than
auto-generated subscribe/unsubscribe email addresses) will require
some sort of database, which is exactly what the first point wants to
avoid !
That's why I believe this should be the job of third party software
that will just pass the job to mod_mbox when it comes to serve a
specific mailing-list archive.
Well, that's all for tonight folks !
Good evening/morning/afternoon,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
|