On Fri, 6 Dec 1996, Jason L Tibbitts III wrote:
> >>>>> "MB" == Michael Brennen <firstname.lastname@example.org> writes:
> MB> I happen to like archive, not archive2, as I don't want my list members
> MB> to have to wade through the ugh of all the headers. Why would it go
> MB> away? Have I missed something?
> First of all, I don't speak for anyone but me. There is, however, a
> consensus among the developers and I believe most of the users that we
> really need to clean things up. The package is kind of messy (although
> progress is being made) and the inclusion of three different archiving
> packages is just confusing to people encountering Majordomo.
No problem with that. I've been with MJ since early 1995, so I understand.
> In addition, everything will eventually be rewritten, and anything that
> isn't rewritten simply won't work well (or at all) in the general
> framework. Of course, if the old archiving program is _completely_
> standalone then there isn't any problem because then it wouldn't depend on
> other pieces of Majordomo. I don't know if it is.
It just replaces archive2 in the aliases, with slightly different options.
> A future version of resend will pass the message off to the archiver itself
> (or perhaps even include the archiver) instead of requiring this to be done
> via aliases. This will have the benefit of including a filtered message
> without things like the message headers and footers and such.
This then would obviate the current versions, and would probably be a good
> The alternative to progress is to straightjacket the maintainers into
> supporting ancient pieces of code in perpetuity. You just aren't going to
> get that with volunteers. A simple solution to being left behind by
> progress is to make certain that the features you need are maintained. You
> can do this by participating (even minimally) in the development process.
> Also, of course, you don't have to upgrade.
I appreciate your point; I was in system software development for 20 years
before launching my own operation two years ago. I follow the development
process, but as a one man operation I have very little time to throw on
development. I wish I did, but I don't.
> As for removing the headers, for the archive to be truly useful you should
> at least keep enough for the file to be read as a folder by a threading
> mail/news reader, and you shouldn't remove any personal headers of any of
> the originators of the messages. So you can basically delete the Received:
> headers and that's about it.
Most of my lists are one way newsletter type lists, and as such the
archives present much better when the receiver can get a cleanly formatted
display when the archive is received. I know what you are saying, but
most of my applications don't really need this.