On September 13, 2002 at 03:10, Mooffie wrote:
MHA has two extension mechanisms (besides filters and charset converters):
1. Callbacks (CBMessageBodyRead, CBRcVarExpand, etc.)
2. mhasiteinit.pl
They both have problems:
1. You can register only one callback for each type.
I know. The callback API is kindof a hack to satisfy some needs
by some users. When I implemented it, I thought, these should be
callback lists, but I was too lazy to do it. I figured if someone
wanted to use MHonArc is such a fancy manner, they could register
a callback wrapper function that would call the sequence of functions
they want to have done.
The API hooks were not intended as a generic plug-in architecture.
The current code base is bad for such a thing, I do not know if I
want to encourage it.
2. You can have only one "mhasiteinit.pl".
3. Setting up "mhasiteinit.pl" may not be straightforward for the end user.
It is intended for users who know Perl.
Side Note: I think your end user classifications are slightly off.
For example, if a user is going to do some Perl coding, then
"abstracting" everything way may provide little use. I.e. A Perl
coder will probably more happy messing with a Perl interface to
MHonArc than messing with a resource file along with Perl code, which
kind of ties into my rant in a different post about redoing
MHonArc's resource manager. If done right, you could interface
with via a resource file or via Perl API calls.
I'm not necessarily disagree with your points, by experience is that if
a MHonArc user does not know Perl, or even how to do real programming,
they will stay away from any resources that are related to code.
And those that do know Perl, have actually patched the code directly
and them me telling them afterwards that what they did could have
been done via resources.
But the site in which MHA was installed already had a "mhasiteinit.pl" with
its own callbacks.
I knew this was possible when added mhasiteinit.pl. I just figured
the use case would never really happen. This is what I get for
exposing some of the internals of a program that should have never
been exposed.
More and more cases are piling up that screams to have MHonArc
redesigned.
2. Allow the user to list all the files he wants to "require" (that is, the
Perl function "require") in the resource file; for example:
<Extensions>
SophisticatedEmailMangler.pl
MyDateFixer.pl
/path/to/hsma/lib/rcvariables.pl
</Extension>
When MHA starts it will require every file that is listed in the <Extensions>
This is still a hack (albeit a better hack than mhasiteinit.pl).
What you really want is a plugin architecture. For example, have
you considered what happens when if some uses mhonarc to process
multiple archives? This can happen via a custom front-end (mharc
uses MHonArc in this way).
So, if we take EXTENSIONS, there probably needs to be API that allows
the extensions to pick up open/close archive events incase they need to
re-initialize themselves when processing a new archive. Probably and
"extension" implements a well defined interface and mhonarc invokes
certain methods at certain points in processing. For example, when
an extension is first required, it calls some onload method. When an
archive is opened, it calls a onarchiveopen method, etc, etc. And,
of course, the extensions should be able to query and modify resources.
This can be done now, but it is ugly since you have to access mhonarc
variables directly.
I guess the decision to make is if the hacks are enough, or if
a serious effort should be made into redesigning MHonArc.
--ewh
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV
