On June 5, 2002 at 13:19, Eugene Eric Kim wrote:
What are your thoughts on the mail parsing modules available on CPAN, and
on using CPAN modules in general? When you start modularizing MHonArc,
are you planning on incorporating CPAN modules, or will you try to avoid
them entirely?
Good question.
A major goal while developing MHonArc was ease of installation, and
I would like to continue that in future developments. For example,
I did not want users to have to bother downloading a bunch of other
stuff just to get things to work (with possibly different installation
messes to deal with). If the system had a proper Perl installation,
one should be able to go through MHonArc's installation process and
be read to go.
Because of this goal, MHonArc currently only requires the use of
modules that are part of every standard Perl distribution. MHonArc 2
will leverage some optional modules, if available, but will fallback
if not available (see the Installation doc for the list of modules).
For MHonArc 3 (or whatever it may be called), I'd like to keep the
same approach. Now, the design should allow the ability to hook in
alternative modules. An example of this already exists in MHonArc 2
where you can actually register the use of MIME::Base64 as the base64
decoder over the one used by MHonArc by default.
As for the part about the parsing modules (which I assume you are
refering to the MIME::* modules), I am not sure. I already have
code that does parsing, so I may go with what I have. Also, MHonArc
has a specific scope of being a filtering/archiving system, so I
do not know if the MIME::* parsing modules will have the potential
internal hooks I may need to make things more efficient and for
the interaction the content-type filters will need.
I'll need to list out the requirements of MHonArc as much as possible
to see if the MIME::* stuff may be worth using. Note: The MIME::*
does require several modules, and I am not sure if all are part
of the standard Perl distribution (relates to installation goal
mentioned above).
Going back to installation issues, I am definitely open to bundling
CPAN modules within MHonArc if there are modules that are essential
for the core or to make things alot easier than trying to replicate
needed functionality already provided by a CPAN module.
Another installation item to consider is if install.me, or something
similiar, should be abandoned in favor of the "standard"-way of
installing Perl software: make Makefile.PL; make; make install
(note, Makefile.PL is currently emulated in MHonArc 2).
There are some things about install.me that I like that I have not
checked are doable with the Makefile.PL approach without basically
re-implementing install.me functionality within it. Two examples I
can think of right now are:
. The setting of the #! line and 'use lib ...' pragma in top-level
programs to make installation of MHonArc in non-standard location
seamless.
. The auto-creation of .bat/.pl version of programs for Win32
systems.
I also like installation process that support prompting of data,
even though there are people who do not like this. I like it since
many regular users (non-geeks) appear to be more comfortable with it,
especially for specifying optional parameters. BTW, when compiling
perl, it has an interactive prompting build/configure process.
I do know that Makefile.PL can be modified to support prompting,
but I do not know how well it is supported by the Make::Maker stuff.
Related to installation is this other goal:
Everything is done in pure-Perl.
I.e. I do not want to have a user have a C compiler on their system
to install MHonArc.
--ewh
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV
