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.
signature.asc
Description: Digital signature
