On Thu, Jun 02, 2005 at 11:35:09AM -0700, Paul Querna wrote: > Shorter Term List: > * Remove automake dependency (pure autoconf+Makefile.in)
Yes, this is a condition before any release given my -1 for automake. =) > * Rename mod-mbox-util. (mboxutil? something else? All I know is that > the current name will change) I'm not a fan of 'busybox' style programs. I think that style of programming makes it too difficult for people to understand as the program tries to do too much. However, I won't push too hard. > * Update trunk/scripts to use mod-mbox-util These should be done in concert with updating the mod_mbox install on ajax. Perhaps this is something we can coordinate at the ApacheCon Hackathon next month? (Honestly, I probably won't have the full two-three days to re-initializing everything until ApacheCon.) > * Add some *basic* documentation on configuration > > Longer Term Things: > > * Interface. This is a SoC project. We need some thoughts on if we > want to use some kind of Theme system (eg, ClearSilver or XSLT) or stick > with hard coded HTML. I think a massive addition of CSS is a given, but > the details are still up in the air. Yup. > * Searching. This is a SoC project. I do have some of the low level > indexing bits done for Lucene4c in trunk. We need further discussion if > we want to even use Lucene4c. Some have suggested using Postgres or > MySQL with their full text indexing tools. Personally, I like using > Lucene4c since it runs right off the file system, and is a > eat-your-own-dog-food type thing. Part of the intention with mod_mbox was not to be tied to a relational database. So, I'm against MySQL or Postgres being mandatory in any form. Lucene4c is by far the best solution and eating our dog food is goodness. > * General Design. Currently, mod_mbox is tied to a single .mbox file, > or optionally, a directory of .mbox files. As we add searching and > improve the interface, we will want the ability to search all mailing > lists, a single list, or maybe all lists under a domain. This means > mod_mbox needs a knowledge of what other lists exist. This is really > about turning mod_mbox into a 'Mail Archive Application' vs just > something that runs off of mbox files. There are advantages and > disadvantages to both directions. For the ASF's use cases, I believe > making it more of a unified application is good. I feel a lot of the power of mod_mbox comes from its core simplicity. I'm ambivalent about joining everything together in a 'single' application. In the past when we did searching (via htdig, etc.), we kept that disconnected from mod_mbox. I'm not sure why searching means that we have to have a 'Mail Archive Application.' So, I would really want to see a lot of thought into why we'd go from a handler based module into an incredibly more complicated (and error-prone!) catch-all system that would override Apache's file logic (groan!). -- justin
