Re: New package: flim 1.14.4
Valdis.Kletnieks(a)vt.edu writes:
On Thu, 01 Aug 2002 02:36:58 +0200, Simon Josefsson
<jas(a)extundo.com> said:
> Unfortunately it also contains a hacked version of mail-lib's
> smtpmail.el, splitted into two new files; smtp.el and smtpmail.el. I
> haven't tested it, and perhaps those files should be removed? Or is
> it possible to make sure mail-lib is always earlier in load-path?
Here there be dangerous and fearsome dragons indeed.
If you remove them, will flim break because it relies on whatever
hacks had been applied? Similarly, if mail-lib is earlier, will
that shadow a needed tweak so it's not available?
I think it will work -- smtp.el and smtpmail.el in FLIM are self
contained. Nothing else in FLIM uses it.
OTOH, another package could potentielly require the FLIM XEmacs
package expecting the hacked smtp.el and smtpmail.el to be present,
which wouldn't work. But this isn't very likely, as it requires
someone to write code blindly.
Is the author accessible, and able to explain why there's a
hacked smtpmail.el?
Knowing the answer to this would go a LONG way to deciding what the
proper thing to do is - particularly if the "right" answer is for us
to pick up a bugfix/extension he made and lose the hacked file.
I asked a long time ago, and then the reason was to add SASL/STARTTLS
support. Looking at the code, that and a general cleanup seems to be
the reason.
In theory one could deprecate smtpmail.el in mail-lib in favor of the
FLIM version, but I'm not sure about I like the FLIM version -- for
one it uses a tiny OOP kernel and lots of other libraries which are
quite opaque and undocumented. Another reason is that I'm not sure
all of the code is assigned to FSF, so it would mean forking the SMTP
code between emacs and xemacs. Oh, and most of the variables seem to
have changed names, too, making it a problematic upgrade for users.
It doesn't sounds like a good idea to me.