>>>>> "WH" == Walt Haas <haas@xmission.com> writes:
WH> Well 2.0 seems to be a little high-centered at the moment. It hasn't
WH> got far enough to attract the kind of user base that will add
WH> development labor to it, but its design is different enough (that's a
WH> compliment, not an objection) from 1.94.4 that it isn't very easy to
WH> just merge the pieces.
I think that's the crux of the matter, but honestly resend in 2.0 already
does most of the things that 1.9x does and more (i.e. it already has
duplicate filtering by message-id, full-body checksum and partial-body
checksum). Things really are done in such a completely different way that
I don't see much hope of merging everything. The pieces that resend
(really the outgoing message-munging module Resend.pm) now needs (like an
implementation of the MIME-munging scheme that was hashed out here) aren't
in 1.9x anyway. An exception is old-style approval, I suppose, but I
thought I rewrote that in a reasonably sensible manner 18 months ago.
In fact, I wonder if people think 2.0 is less far along than it really is?
There really is a lot of stuff there. In getting back into development I'm
realizing that more than when I had it all in memory. Unfortunately a lot
of the work I'm doing is internal; tweaking the interface here, relocating
a set of functionality there. And there are definitely lots of bugs.
WH> I'd like to contribute in some way that will move 2.0 forward while
WH> solving my client's problem in a way that leads to my earning enough
WH> money to buy groceries.
I wish there was a way to do this. Besides the fact that anything in 2.0
is going to be almost by definition non-perl4-compatible, I sometimes wish
I hadn't chosen to go off on such a completely different track, but then I
look at the 1.9x source and feel much better. Perhaps that's just because
I'm responsible for almost all of 2.0 and it's really just as bad, but I
really hope not and honestly don't think so. 2.0 is complicated - perhaps
too complicated - but it does have a relatively rigid internal structure
and the various pieces of functionality are very compartmentalized.
One thing that does translate well is ideas; if you figure out a good way
to implement something (in an abstract sense) and you find that it really
does solve the problem then it will still apply to 2.0 even though the code
might not. I don't see this as a problem. Chuq is doing many things like
this.
In your case, though, 2.0 (theoretically) already supports what your trying
to do, and in addition might make it irrelevant. To wit, resend (really
the 'post' function from Resend.pm) goes through the message and figures
out everything that's wrong with it. Then it ships all of that off to the
access control system, which lets the list owner (via a simple programming
language) perform various actions like allowing the action, consulting the
owner, confirming the action with the 'victim', not allowing the action,
sending a message back to the requestor, etc. You can do multiples, too.
(allow and send a message, reject and send a message, etc.)
In addition, there is some other (unfortunately not completely orthogonal
functionality) that allows list members to request information on the
progress of their messages through the system, so that they can be informed
if a message is tripped up by an administrivia filter.
All of this is of course modulo any bugs or screwed-up implementations.
WH> After this list showed little to zero enthusiasm for my 1.94.4
WH> documentation I posted the URL to the majordomo-users list, and got two
WH> (count `em, 2) responses.
Sorry if I wasn't enthusiastic; I'm way out of 1.9x mode most of the time.
WH> But just for the sake of argument, suppose that I spent some time
WH> reading the code for 2.0 and compiled a bunch of notes about the pieces
WH> and how they fit together and stuff like that, in what form might any
WH> hypothetical reader want the documentation?
Text or POD is what I'd prefer, simply because it's simple and there's
rarely a need for anything more involved. If you're doing something fancy
which needs graphics then use whatever you feel like (see the VCG-based
graphs I generated for the module dependencies). And since I plan for any
and all useful user and owner documentation to be available from within
Majordomo, so nobody can claim not to have access to list-owner-info, I
suppose it really should be text. (Though an argument can be made for HTML
with Majordomo internally converting to text, so that a web interface gets
some goodies almost for free.) BTW, the method for all of the
documentation to be incorporated is already there. The help command takes
arguments and can return an unlimited number of documents.
Finally, if you do want to talk about how to accomplish what you need to do
in 1.9x, I can probably come up with some ideas. I don't think we're
talking about something terribly difficult here, assuming that you know
where in the code to put it.
- J<
References:
|
|
