Ville Skyttä <ville.skytta(a)xemacs.org> writes:
> On second thought it might make sense to extract the SASL parts
of
> FLIM into a separate library -- that's the part I really was
> interested in. Then the gnus, sieve, mail-lib and possibly others can
> require the sasl package. Which does not depend on APEL. What do you
> think?
Sounds good. Of course, this means that we're a bit more on our own
regarding upstream support and communication. Maybe this should be
discussed with the authors, if they'd be willing to split the SASL stuff
out of the FLIM package?
It was blessed by the main SASL author (see emacs-mime-en list),
that's enough for me.
Ok, I have committed a SASL package in unsupported/simon/sasl/ now,
and updated the ECRYPTO package in unsupported/simon/ecrypto/ which
contains some files that SASL needs. ECRYPTO includes md5, which
might not be needed, how far back in XEmacs versions are packages
supposed to support? MD5 has been core functionality for quite a
while. It shouldn't be harmful though, so I think it is safest to
leave it in, unless someone has another opinion. Gnus and W3 packages
also includes md5.el, btw.
Moving the directories into xemacs-packages/ and updating Makefile and
package-info.in should be enough. Wha'd'ya say? I have even done
some minimal testing, so it might even work.
Once the SASL package is installed I'll update the SIEVE package (and
Oort Gnus) to use it, wait a few months for feedback and then modify
smtpmail.el too, if the Emacs maintainers will accept the SASL library
and the smtpmail modifications. (Emacs will most likely get the SASL
library anyway, via Oort Gnus, but installing the SASL library earlier
and making smtpmail.el use it could be good.)