1:36 a.m.
I added a new package into unsupported/simon/flim/.
What do people think about making it an official package? It
contains, among other things, a SASL elisp library, which I'm trying
to make Gnus use. The Sieve package can take advantage of it
immediately though.
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?
To make it an official package, moving the directory into
../../../xemacs-packages/ on the CVS server should work (this is how I
compile it, I haven't gotten the build system in unsupported/ to
work).
Of course, I have barely tried the package so it needs reviewing.
2 a.m.
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?
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.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
2:24 a.m.
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.
11:39 a.m.
On Thu, 2002-08-01 at 03:36, Simon Josefsson wrote:
I added a new package into unsupported/simon/flim/.
What do people think about making it an official package? It
contains, among other things, a SASL elisp library, which I'm trying
to make Gnus use. The Sieve package can take advantage of it
immediately though.
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?
Eek. At least this needs considerable testing before we make it
official.
To make it an official package, moving the directory into
../../../xemacs-packages/ on the CVS server should work (this is how I
compile it, I haven't gotten the build system in unsupported/ to
work).
Please don't do that. Build problems in the unsupported area are
usually due to missing entries of *official* required packages from
unsupported/package-compile.el (package-directory-map). Or buggy
Makefiles. For example, flim requires apel, which wasn't in that list
(I've added it a couple of minutes ago).
Of course, I have barely tried the package so it needs reviewing.
Yep. And the dependency of APEL worries me too, given the recent
troubles and the somewhat uncertain future of it as a xemacs package.
--
\/ille Skyttä
ville.skytta at xemacs.org
11:46 a.m.
Ville Skyttä <ville.skytta(a)xemacs.org> writes:
On Thu, 2002-08-01 at 03:36, Simon Josefsson wrote:
> I added a new package into unsupported/simon/flim/.
>
> What do people think about making it an official package? It
> contains, among other things, a SASL elisp library, which I'm trying
> to make Gnus use. The Sieve package can take advantage of it
> immediately though.
>
> 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?
Eek. At least this needs considerable testing before we make it
official.
The smtp stuff from FLIM should not be used IMHO.
> To make it an official package, moving the directory into
> ../../../xemacs-packages/ on the CVS server should work (this is how I
> compile it, I haven't gotten the build system in unsupported/ to
> work).
Please don't do that. Build problems in the unsupported area are
usually due to missing entries of *official* required packages from
unsupported/package-compile.el (package-directory-map). Or buggy
Makefiles. For example, flim requires apel, which wasn't in that list
(I've added it a couple of minutes ago).
Ah, now it works. Thanks.
> Of course, I have barely tried the package so it needs
reviewing.
Yep. And the dependency of APEL worries me too, given the recent
troubles and the somewhat uncertain future of it as a xemacs package.
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?
1:03 p.m.
On Thu, 2002-08-01 at 13:46, Simon Josefsson wrote:
>> Of course, I have barely tried the package so it needs
reviewing.
>
> Yep. And the dependency of APEL worries me too, given the recent
> troubles and the somewhat uncertain future of it as a xemacs package.
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?
--
\/ille Skyttä
ville.skytta at xemacs.org
1:24 p.m.
Ville Skyttä <ville.skytta(a)xemacs.org> writes:
On Thu, 2002-08-01 at 13:46, Simon Josefsson wrote:
> >> Of course, I have barely tried the package so it needs reviewing.
> >
> > Yep. And the dependency of APEL worries me too, given the recent
> > troubles and the somewhat uncertain future of it as a xemacs package.
>
> 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?
I'll ask. One of the authors said it was fine to include the SASL
stuff in Gnus though, without the rest of FLIM. Actually the author
didn't seem to be aware it was part of FLIM (see discussion on the
ding list). I don't think this would cause much problems, as SASL
does not depend on FLIM. If we at some point want to package all of
FLIM, it can simply require SASL for the SASL files.
9:59 p.m.
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.)
11:16 p.m.
On Fri, 2002-08-02 at 23:59, Simon Josefsson wrote:
>> 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.
Cool, enough for me too.
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.
ISTR somebody talked something about licensing issues with ecrypto (the
IDEA code)? If this was the case and/or if it can be left out, let's
leave it.
AFAIK, XEmacs packages should work with 21.1 and newer.
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.
Nice:) I mailed about docbookide, ocaml and sml-mode earlier today,
let's move sasl in the same batch with them. I suppose a repository
move would be the way to do it this time...
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.)
Sounds like a good plan to me.
Cheers,
--
\/ille Skyttä
ville.skytta at xemacs.org
11:29 p.m.
Ville Skyttä <ville.skytta(a)xemacs.org> writes:
> 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.
ISTR somebody talked something about licensing issues with ecrypto (the
IDEA code)? If this was the case and/or if it can be left out, let's
leave it.
Ah, yes, IDEA is patented in some countries (but not all). I'd
distribute it and fight the IDEA people in court, but I guess they
won't be suing me if XEmacs distribute it, so I removed it to save
someone else from the trouble. If someone responsible is willing to
fight them in court, I think it would make a nice statement to include
it though.
AFAIK, XEmacs packages should work with 21.1 and newer.
OK. md5 is needed then.
> 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.
Nice:) I mailed about docbookide, ocaml and sml-mode earlier today,
let's move sasl in the same batch with them. I suppose a repository
move would be the way to do it this time...
Yup.
3:54 a.m.
>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> I added a new package into unsupported/simon/flim/.
Simon> What do people think about making it an official package?
Let's not unless GNU Emacs does. The authors have a long history of
doing things their undocumented way at the expense of other packages
and users. These are the same people who brought us APEL, tm, SEMI,
and UTF-2000 XEmacs, all excellent products in their own ways, but not
very easy to cooperate with.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
10:45 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> I added a new package into unsupported/simon/flim/.
Simon> What do people think about making it an official package?
Let's not unless GNU Emacs does. The authors have a long history of
doing things their undocumented way at the expense of other packages
and users. These are the same people who brought us APEL, tm, SEMI,
and UTF-2000 XEmacs, all excellent products in their own ways, but not
very easy to cooperate with.
Only the SASL library from FLIM was added (which, btw, is standalone
and does not depend on APEL or anything else). Most of it has been
assigned to FSF, and I believe the remaining part is under way. I'll
ask FSF about papers, and then I'll send a patch to emacs-devel with a
patch. I think Oort Gnus is likely to use it soon too, so eventually
it probably ends up in emacs.
10:51 a.m.
>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> Only the SASL library from FLIM was added (which, btw, is
Simon> standalone and does not depend on APEL or anything else).
Oh, OK. Small libraries aren't a problem as long as they don't bring
dependencies like APEL along with them.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8142
days inactive
8149
days old
12 comments
4 participants
participants (4)
-
Simon Josefsson -
Stephen J. Turnbull -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks -
Ville Skyttä