You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Maxime Petazzoni <ma...@bulix.org> on 2006/01/10 17:56:38 UTC
mod_mbox helper scripts and programs
Hi,
First, I would like to bring back (again) the subject of mod_mbox
helper scripts and program on the table.
I understand why these scripts are important in order to maintain the
ASF mail archives website. These scripts call some helper programs
(actually contained in the trunk/module-2.0/ directory) to process the
mailbox files.
Unfortunately, these programs do not compile anymore due to some API
changes in the mbox_* files a while ago, and maybe even before the
Google's Summer Of Code (the problem comes from changes to lunece4c
related functions, that I did not touch). That's why I would like to
have more information about how the ASF archives are maintained, and
how can you make this work if the helper programs do not compile.
I guess you've been using binaries compiled long ago, before the API
breakage, but since a lot of improvments and changes in the APR during
this period of time, I just wonder how the whole thing can
work.
Next, I would like to make you notice that these scripts do not belong
the the module's source code because they are not useful and made for
the mod_mbox user (as an admin) but only for an internal purpose. Thus
I propose that we move the scripts directory one level up :
branches/
tags/
trunk/
scripts/
Since we do not release, tag or branch these scripts, this is not a
problem to break the traditionnal Svn schema here.
Finally, I would like to know your feelings about the surgery branch
that was created a few weeks ago : the module is operational and this
branch provide a cleaner and more evolutive directory structure, as
well as a complete untabification of the source code (blame my lack of
Emacs configuration on this point, this is now fixed once and for
all).
Personnaly, I would like to see these points solved and the surgery
branch merged back to trunk so I can create a 0.2.1 tarball and then
try to (finally) release it.
Thank you for your attention,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: mod_mbox helper scripts and programs
Posted by Maxime Petazzoni <ma...@bulix.org>.
* Maxime Petazzoni <ma...@bulix.org> [2006-01-10 17:56:38]:
> Finally, I would like to know your feelings about the surgery branch
> that was created a few weeks ago : the module is operational and this
> branch provide a cleaner and more evolutive directory structure, as
> well as a complete untabification of the source code (blame my lack of
> Emacs configuration on this point, this is now fixed once and for
> all).
>
> Personnaly, I would like to see these points solved and the surgery
> branch merged back to trunk so I can create a 0.2.1 tarball and then
> try to (finally) release it.
And about this point, any comments ? It's not that the script war is
starting to get on my nerves, but I'd like to move on.
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: mod_mbox helper scripts and programs
Posted by Paul A Houle <ph...@cornell.edu>.
Justin Erenkrantz wrote:
> On Tue, Jan 10, 2006 at 06:55:37PM +0100, Mads Toftum wrote:
>
>> On Tue, Jan 10, 2006 at 09:51:36AM -0800, Paul Querna wrote:
>>
>>> Python!
>>>
>> Excellent choice - at least that way I won't have to even consider
>> trying ;)
>>
>
> Even Perl would be an improvement over zsh. =) -- justin
>
>
I'd learn towards Perl. You're more likely to find Perl installed
on a system than Python.
Re: mod_mbox helper scripts and programs
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Justin Erenkrantz wrote:
> On Tue, Jan 10, 2006 at 06:55:37PM +0100, Mads Toftum wrote:
>> On Tue, Jan 10, 2006 at 09:51:36AM -0800, Paul Querna wrote:
>>> Python!
>> Excellent choice - at least that way I won't have to even consider
>> trying ;)
>
> Even Perl would be an improvement over zsh. =) -- justin
I realize I haven't been involved, but been reading this stuff.....
I'm voting PERL on the basis more that I think more people tend to be
familiar with it. (including me :))
--
------------------------------------------------------------------------
"Love is not the one you can picture yourself marrying,
but the one you can't picture the rest of your life without."
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
"I wanna hold ya till I die ... I wanna hold ya till the fear in me
subsides."
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
Re: mod_mbox helper scripts and programs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jan 10, 2006 at 06:55:37PM +0100, Mads Toftum wrote:
> On Tue, Jan 10, 2006 at 09:51:36AM -0800, Paul Querna wrote:
> > Python!
>
> Excellent choice - at least that way I won't have to even consider
> trying ;)
Even Perl would be an improvement over zsh. =) -- justin
Re: mod_mbox helper scripts and programs
Posted by Mads Toftum <ma...@toftum.dk>.
On Tue, Jan 10, 2006 at 09:51:36AM -0800, Paul Querna wrote:
> Python!
Excellent choice - at least that way I won't have to even consider
trying ;)
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
Re: mod_mbox helper scripts and programs
Posted by Paul Querna <ch...@force-elite.com>.
Mads Toftum wrote:
> On Tue, Jan 10, 2006 at 09:22:18AM -0800, Justin Erenkrantz wrote:
>> I think they do belong and should be included in a release. Namely, I
>> don't buy Roy's arguments against including them. The potential benefit to
>> understanding how mod_mbox works outweighs the slight cost of including
>> some small scripts. If anyone ever bothers to rewrite them, more power to
>> them. However, not including *any* documentation or examples in the
>> tarball seems much worse than excluding these scripts.
>>
> Agreed - they should at least be kept until there's a usable
> replacement either in the form of good docs or scripts rewritten to
> something slightly more commonly used than zsh.
> If "someone" were to contemplate making a general version of those
> scripts - what would have a reasonable chance of getting accepted? perl?
> ksh? C?
Python!
Re: mod_mbox helper scripts and programs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jan 10, 2006 at 06:47:42PM +0100, Maxime Petazzoni wrote:
> * Mads Toftum <ma...@toftum.dk> [2006-01-10 18:44:51]:
>
> > If "someone" were to contemplate making a general version of those
> > scripts - what would have a reasonable chance of getting accepted? perl?
> > ksh? C?
>
> I don't see why these scripts have to run with Zsh. They should be
> able to run with SH w/o problems.
sh is not powerful enough. The scripts rely on a lot of features that are
only in zsh.
> If not, Perl would be indeed a better solution since it is more spread
> than Python.
If I were doing it again, I'd do it in Python. But, don't let that dictate
the final decision. =) -- justin
Re: mod_mbox helper scripts and programs
Posted by Maxime Petazzoni <ma...@bulix.org>.
* Mads Toftum <ma...@toftum.dk> [2006-01-10 18:44:51]:
> If "someone" were to contemplate making a general version of those
> scripts - what would have a reasonable chance of getting accepted? perl?
> ksh? C?
I don't see why these scripts have to run with Zsh. They should be
able to run with SH w/o problems.
If not, Perl would be indeed a better solution since it is more spread
than Python.
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: mod_mbox helper scripts and programs
Posted by Mads Toftum <ma...@toftum.dk>.
On Tue, Jan 10, 2006 at 09:22:18AM -0800, Justin Erenkrantz wrote:
> I think they do belong and should be included in a release. Namely, I
> don't buy Roy's arguments against including them. The potential benefit to
> understanding how mod_mbox works outweighs the slight cost of including
> some small scripts. If anyone ever bothers to rewrite them, more power to
> them. However, not including *any* documentation or examples in the
> tarball seems much worse than excluding these scripts.
>
Agreed - they should at least be kept until there's a usable
replacement either in the form of good docs or scripts rewritten to
something slightly more commonly used than zsh.
If "someone" were to contemplate making a general version of those
scripts - what would have a reasonable chance of getting accepted? perl?
ksh? C?
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
Re: mod_mbox helper scripts and programs
Posted by Maxime Petazzoni <ma...@bulix.org>.
* Justin Erenkrantz <ju...@erenkrantz.com> [2006-01-10 09:56:56]:
> On Tue, Jan 10, 2006 at 06:43:53PM +0100, Maxime Petazzoni wrote:
> > If one is able to build mod_mbox and make Apache use it, he is also
> > able to setup his archives as described in the online documentation.
>
> What documentation? The mod_mbox pages on our website don't give any
> information on how to feed it with rsync.
Yeah, because the ASF is probably the only entity using mod_mbox for
his *own* archives, which are retreived via Rsync.
This is NOT the case of everybody. Just a few days ago, I received an
email from someone who set up mod_mbox succesfully from his
month-splitted mbox files. Do you see any rsync in there ?
Btw, you are making the same confusion with the scripts : they are for
ASF purposes only, or even for your purposes. Yeah, that's your
account name on the top of all of them.
> An example included in the tarball is worth a lot more than info on a
> website. Also, bundling those docs from the website in the tarball would
> be a help too. -- justin
+1 here. We should copy the mod_mbox/ directory from the website
before creating the tarball.
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: mod_mbox helper scripts and programs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jan 10, 2006 at 06:43:53PM +0100, Maxime Petazzoni wrote:
> If one is able to build mod_mbox and make Apache use it, he is also
> able to setup his archives as described in the online documentation.
What documentation? The mod_mbox pages on our website don't give any
information on how to feed it with rsync.
(And, there is *some* documentation in the scripts/README.)
An example included in the tarball is worth a lot more than info on a
website. Also, bundling those docs from the website in the tarball would
be a help too. -- justin
Re: mod_mbox helper scripts and programs
Posted by Maxime Petazzoni <ma...@bulix.org>.
Hi,
* Justin Erenkrantz <ju...@erenkrantz.com> [2006-01-10 09:22:18]:
> > I guess you've been using binaries compiled long ago, before the API
> > breakage, but since a lot of improvments and changes in the APR during
> > this period of time, I just wonder how the whole thing can
> > work.
>
> No. The scripts use mod-mbox-util.
Hum, it's a bit strange to have this fallback to the helper programs,
anyway I'm pleased to know that this still works.
> > Next, I would like to make you notice that these scripts do not belong
> > the the module's source code because they are not useful and made for
> > the mod_mbox user (as an admin) but only for an internal purpose. Thus
> > I propose that we move the scripts directory one level up :
>
> I think they do belong and should be included in a release. Namely, I
> don't buy Roy's arguments against including them. The potential benefit to
> understanding how mod_mbox works outweighs the slight cost of including
> some small scripts. If anyone ever bothers to rewrite them, more power to
> them. However, not including *any* documentation or examples in the
> tarball seems much worse than excluding these scripts.
And having a bunch of non-understandable scripts is maybe worse : they
make mod_mbox looks complicated, something it is not.
Again, I don't see how these scripts help. There are not documented,
and they don't seem to do much more than an rsync, some
renaming/linking and calling mod-mbox-util. Having a dozen of scripts
doing basically the same thing, without any documentation on how they
work and on the mbox-archives.conf file you seem to provide them
... Nah, that's useless.
If one is able to build mod_mbox and make Apache use it, he is also
able to setup his archives as described in the online documentation.
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
Re: mod_mbox helper scripts and programs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jan 10, 2006 at 05:56:38PM +0100, Maxime Petazzoni wrote:
> I understand why these scripts are important in order to maintain the
> ASF mail archives website. These scripts call some helper programs
> (actually contained in the trunk/module-2.0/ directory) to process the
> mailbox files.
No, they don't. They can call either mod-mbox-util or the helper apps. (I
really don't like mod-mbox-util - busybox still apps are awful and are
confusing to understand; but I obviously lost that battle.)
I think without these scripts mod_mbox is largely useless. You need some
scripts to help generate the archives. So, even though they are customized
for our setup, they are a help (in the category of 'better than nothing')
to users who would download mod_mbox to help understand how it all works
together to create a real archive site on the backend.
> I guess you've been using binaries compiled long ago, before the API
> breakage, but since a lot of improvments and changes in the APR during
> this period of time, I just wonder how the whole thing can
> work.
No. The scripts use mod-mbox-util.
> Next, I would like to make you notice that these scripts do not belong
> the the module's source code because they are not useful and made for
> the mod_mbox user (as an admin) but only for an internal purpose. Thus
> I propose that we move the scripts directory one level up :
I think they do belong and should be included in a release. Namely, I
don't buy Roy's arguments against including them. The potential benefit to
understanding how mod_mbox works outweighs the slight cost of including
some small scripts. If anyone ever bothers to rewrite them, more power to
them. However, not including *any* documentation or examples in the
tarball seems much worse than excluding these scripts.
If we had a full on manual that explains how someone would set up a real
archive site with mod_mbox, and a useful README file, maybe I would think
differently - but we don't. -- justin