Re: pop3.el itegration with netrc.el

Re: pop3.el itegration with netrc.el

[Ted Zlatanov]

On Thu, 14 Oct 2004, jas@extundo.com wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
> 
>> pop3.el seems to be separate from the rest of Gnus, so I'm not sure if
>> I should add netrc.el (authinfo) support to it - then pop3.el would
>> also depend on gnus-encrypt.el.  Please advise.
> 
> There are many incompatible forks of pop3.el, the copy in Gnus CVS
> used to be one of them.  I see now that the copies in Gnus CVS and
> Emacs CVS are in sync.  I'm not sure how that happened, but it is a
> good thing.  So perhaps we can make this one the canonical copy, and
> add new features to it.  I'd say go ahead.

I've cc-ed the emacs-devel list in case anyone there has suggestions.
This is regarding pop3.el and its use of netrc (~/.authinfo) files.

> Btw, is it difficult to modularize gnus-encrypt.el into, say,
> encrypt.el, that doesn't use a lot of Gnus functions?  I recall some
> discussions about that, though.

This may be a good time to make that break.  The current
gnus-encrypt.el can be turned into encrypt.el with very few changes
except for the dependency on password.el, which is in Gnus.
gnus-encrypt.el will remain as a wrapper for Gnus, using password.el
and allowing closer integration with other Gnus libraries.  This is
not the real problem, though.

The root problem is that netrc.el is a part of Gnus I can't break out
(I think), so the Gnus version of pop3.el will have a dependency we
don't want.  Maybe we should have gnus-pop3.el to implement what I'm
proposing, so pop3.el remains clean of Gnus dependencies?

Ted

Re: pop3.el itegration with netrc.el

[Simon Josefsson]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

>> Btw, is it difficult to modularize gnus-encrypt.el into, say,
>> encrypt.el, that doesn't use a lot of Gnus functions?  I recall some
>> discussions about that, though.
>
> This may be a good time to make that break.  The current
> gnus-encrypt.el can be turned into encrypt.el with very few changes
> except for the dependency on password.el, which is in Gnus.

We can install password.el in Emacs.

> The root problem is that netrc.el is a part of Gnus I can't break out
> (I think)

Why not?  Doing so seem like a good idea, to me.  netrc.el doesn't
call any Gnus functions, except for gnus-encrypt, as far as I can
tell.  And if we (you) move gnus-encrypt.el to encrypt.el, all will be
fine, I think.

> so the Gnus version of pop3.el will have a dependency we don't want.

pop3.el would depend on netrc.el, which would depend on encrypt.el,
which would depend on password.el.  All small files, and no Gnus
dependencies.

encrypt.el (was: pop3.el itegration with netrc.el)

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Fri, 15 Oct 2004, reinersteib+gmane@imap.cc wrote:

> password.el and encrypt.el (tla, ...) are new in No Gnus.  So these
> files will not be considered now, I think.

encrypt.el should be general-purpose enough that it can be outside
Gnus itself.  I would like it to be part of Emacs, not just Gnus,
because encryption is important to users and Emacs doesn't come with
much built-in for handling encryption.  I'm attaching a copy, the same
(as of now) as the one in the Gnus CVS HEAD.  Can anyone comment on
the likelihood of inclusion in Emacs?

The current list of encryption methods is minimal but can be easily
expanded.  The API is IMHO more important.

Thanks
Ted


[-- Attachment #2: encrypt.el --]
[-- Type: application/emacs-lisp, Size: 9233 bytes --]

Re: encrypt.el

[Simon Josefsson]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> encrypt.el should be general-purpose enough that it can be outside
> Gnus itself.  I would like it to be part of Emacs, not just Gnus,
> because encryption is important to users and Emacs doesn't come with
> much built-in for handling encryption.  I'm attaching a copy, the same
> (as of now) as the one in the Gnus CVS HEAD.  Can anyone comment on
> the likelihood of inclusion in Emacs?

For the emacs-devel audience, it may be useful to highlight one
potentially controversial aspect of it:

It is a wrapper around ENCRYPTION code.

As far as I recall, RMS said that encryption code is OK now, that's
why tls.el and starttls.el eventually was added to Emacs.

I support including it.

Re: encrypt.el

[Richard Stallman]

You're my main advisor on encryption; if you think that encrypt.el
does the right things, I would be glad to see it moved out of Gnus.
Doing this requires writing text for etc/NEWS and for the Lisp manual.

However, there is one thing in encrypt.el that seems strange
and perhaps a bug:

    (defcustom encrypt-password-cache-expiry 200
      "Encryption password timeout.
    When set, directly sets password-cache-expiry"
      :type 'integer
      :group 'encrypt
      :set (lambda (symbol value)
	     (set symbol value)
	     (setq password-cache-expiry value)))

What job is this supposed to do?  Is this the right way
to do that job?  Perhaps putting password-cache-expiry
into this custom broup is the right solution.

Re: encrypt.el

[Ted Zlatanov]

On Sat, 16 Oct 2004, rms@gnu.org wrote:

> You're my main advisor on encryption; if you think that encrypt.el
> does the right things, I would be glad to see it moved out of Gnus.
> Doing this requires writing text for etc/NEWS and for the Lisp
> manual.

I can do that.  I am concerned that I don't have Emacs CVS access,
though, in case I need to make changes to the code I'll be
maintaining.

> However, there is one thing in encrypt.el that seems strange
> and perhaps a bug:
> 
>     (defcustom encrypt-password-cache-expiry 200
>       "Encryption password timeout.
>     When set, directly sets password-cache-expiry"
>       :type 'integer
>       :group 'encrypt
>       :set (lambda (symbol value)
> 	     (set symbol value)
> 	     (setq password-cache-expiry value)))
> 
> What job is this supposed to do?  Is this the right way
> to do that job?  Perhaps putting password-cache-expiry
> into this custom broup is the right solution.

I think your way is much better, but I was thinking of the manual on
the :group keyword:

     If you use this keyword more than once, you can put a single item
     into more than one group.  Displaying any of those groups will
     show this item.  Please don't overdo this, since the result would
     be annoying.

Perhaps it would be better to default encrypt-password-cache-expiry to
'default, which would use password-cache-expiry, and also allow a
numeric value which would override password-cache-expiry.  The reason
is that if password.el is used in Emacs, the general password cache
expiry is not necessarily what you want for encryption cache expiry.

Please let me know what you think.

Ted

Re: encrypt.el

[Miles Bader]

Ted Zlatanov <tzz@lifelogs.com> writes:
>> You're my main advisor on encryption; if you think that encrypt.el
>> does the right things, I would be glad to see it moved out of Gnus.
>> Doing this requires writing text for etc/NEWS and for the Lisp
>> manual.
>
> I can do that.  I am concerned that I don't have Emacs CVS access,
> though, in case I need to make changes to the code I'll be
> maintaining.

I don't see any reason why you couldn't get Emacs CVS access if you're
maintaining a file there!

Note that if you change the file in Emacs CVS, those changes will go
into the Gnus v5-10 branch too, as "encrypt.el" is currently `the same
file' as "gnus-encrypt.el" (and more generally, since presumably Emacs
Gnus will be changed to use the new "encrypt.el", those changes also
will be propagated to the Gnus v5-10 branch).

So keeping this in mind, you could theoretically just do the opposite:
install your changes into the Gnus v5-10 and have them propagate to
Emacs CVS (and the Gnus CVS trunk) that way.  Because of the "gnus file
vs. non-gnus file" distinction, I would normally be more suspicious of
propagating big changes to a non-gnus file without some discussion, but
this could be relaxed if I know you're also the Emacs maintainer for
that file.

However, you probably need Emacs CVS access anyway, because surely some
Emacs files will use encrypt.el which aren't in the Gnus tree.

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: encrypt.el

[Miles Bader]

Miles Bader <miles@lsi.nec.co.jp> writes:
> However, you probably need Emacs CVS access anyway, because surely some
> Emacs files will use encrypt.el which aren't in the Gnus tree.

BTW, just to add even more verbose explanation about the syncing thing:

Basically my idea is that the Emacs-Gnus gateway will cause all common
files in Emacs and Gnus v5-10 to be identical except when there's a very
good reason (e.g., the Gnus version string in Emacs says "5.11", but the
v5-10 version string remains "5.10.whatever").  Furthermore, all changes
in these files in either Emacs or the v5-10 branch will be installed
into the Gnus CVS trunk, again except where there's a good reason
(typically so far the only exception has been that the changes already
exist in the trunk in modified form).  Because of this, when the next
Emacs Gnus upgrade comes, it should be very easy -- just plonk in the
files from the Gnus trunk without worrying about lost changes from the
Emacs tree.

The effect of this is that as hacker, you should generally only have to
make changes in one place:

  1) If it's a file which is thought of as being outside of Gnus (e.g.,
     the new "encrypt.el"), you should probably make the change in the
     Emacs tree, and it will show up in the Gnus tree a few days later.

     If you don't have Emacs CVS access (or it's inconvenient), you can
     change such a file in the v5-10 branch, and it should propagate to
     Emacs CVS -- however, it will get some extra scrutiny (by me) to see
     if the changes are possibly controversial and need discussion on the
     mailing list.  [Many changes are obvious bug-fixes however, so often
     there won't be any problem.]

  2) If it's to a Gnus file, and it's important enough that it should be
     part of Emacs/v5-10, then you can make the change on the v5-10
     branch, and it will go into Emacs CVS and the Gnus CVS trunk (a few
     days later).

     If you know that there will be conflicts (perhaps because the
     affected source code is different in v5-10 and the Gnus CVS trunk),
     then you can install your change in both places, and when I try to
     sync them, there will be a conflict -- however, since in most such
     cases there would be a conflict _anyway_, it's often easier for me
     to resolve it simply if I see two "identical" changes, and can just
     choose the proper one, rather than having to actually fix the code.

  3) For general Gnus development changes, of course you just make the
     change on the Gnus CVS trunk and it goes into Emacs a few years
     later... :-)

Of course in any case, if you just can't wait for me to sync your
change, you can commit it in more than one place and probably there will
be no problem; usually the changes are textually identical anyway, so
can be easily resolved automatically (sometimes I notice silly things in
such multiple commits, like whitespace differences, and unify those ;-).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: encrypt.el

[Richard Stallman]

    Perhaps it would be better to default encrypt-password-cache-expiry to
    'default, which would use password-cache-expiry, and also allow a
    numeric value which would override password-cache-expiry.

That sounds good.  So I would like someone to move encrypt.el into
Emacs, and to make this change in it.

Re: encrypt.el

[Ted Zlatanov]

On Tue, 19 Oct 2004, rms@gnu.org wrote:

    > Perhaps it would be better to default encrypt-password-cache-expiry to
>     'default, which would use password-cache-expiry, and also allow a
>     numeric value which would override password-cache-expiry.
> 
> That sounds good.  So I would like someone to move encrypt.el into
> Emacs, and to make this change in it.

I can make this change and add documentation for encrypt.el.  I just
need to know who will import my changes into the Emacs CVS.

Ted

Re: encrypt.el

[Miles Bader]

On Thu, Oct 21, 2004 at 02:47:23PM -0400, Ted Zlatanov wrote:
> > That sounds good.  So I would like someone to move encrypt.el into
> > Emacs, and to make this change in it.
> 
> I can make this change and add documentation for encrypt.el.  I just
> need to know who will import my changes into the Emacs CVS.

You should get Emacs CVS access, but I'm not sure how you do that...

For the actual code changes, just commit changes and new files to the
Gnus v5-10 branch, and I'll make sure they end up in the right place in
Emacs (and perhaps post necessary instructions to this list; lisp/ for
encrypt.el?).  [netrc.el is already a common file, so changes to that
should propagate]

For not-in-Gnus changes (NEWS + non-Gnus .texi changes?), you can either
send me diffs, or wait until you have Emacs CVS access.

-Miles
-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: encrypt.el

[Miles Bader]

p.s.:  Can you remove gnus-encrypt.el from the Gnus trunk now?

Thanks,

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: encrypt.el

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> You should get Emacs CVS access, but I'm not sure how you do that...

You can do that from the admin page for the Emacs project on savannah.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: encrypt.el

[Miles Bader]

Andreas Schwab <schwab@suse.de> writes:
>> You should get Emacs CVS access, but I'm not sure how you do that...
>
> You can do that from the admin page for the Emacs project on savannah.

Hmmm, actually I didn't realize I was an Emacs admin on savannah but
apparently I am!  I'll see if I can figure out how to do it.

[Richard -- from your previous messages, I assume having Ted work on
this stuff directly in Emacs CVS is OK, but please confirm.]

Thanks,

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: encrypt.el

[Richard Stallman]

    [Richard -- from your previous messages, I assume having Ted work on
    this stuff directly in Emacs CVS is OK, but please confirm.]

Yes, it is ok.

Re: encrypt.el

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: Fri, 22 Oct 2004 09:35:38 +0900
> Cc: Ted Zlatanov <tzz@lifelogs.com>, rms@gnu.org, emacs-devel@gnu.org
> 
> I'll see if I can figure out how to do it.

Let me know if you need help figuring this out, as I did that many
times.

Re: encrypt.el

[Ted Zlatanov]

On 21 Oct 2004, tzz@lifelogs.com wrote:

> I can make this change [move encrypt.el to lisp/] and add
> documentation for encrypt.el.  I just need to know who will import
> my changes into the Emacs CVS.

I now have CVS access for Emacs so I will do this.  I need to clarify,
however, how encrypt.el will coexist with the Gnus version.  Should I
remove encrypt.el from Gnus, or leave it in as a duplicate of the
Emacs tree version?

If I remove encrypt.el from Gnus, I will also ask that it be added to
the XEmacs source tree, or I'll put it in gnus/lisp/contrib/.  I know
as of yesterday, encrypt.el was treated as part of Gnus in XEmacs,
while netrc.el was not (netrc.el being the main reason why encrypt.el
is needed).  Please advise if you have different opinions on this
matter.

Thanks!
Ted

Re: encrypt.el

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On 21 Oct 2004, tzz@lifelogs.com wrote:
>
>> I can make this change [move encrypt.el to lisp/] and add
>> documentation for encrypt.el.  I just need to know who will import
>> my changes into the Emacs CVS.
>
> I now have CVS access for Emacs so I will do this.  I need to clarify,
> however, how encrypt.el will coexist with the Gnus version.  Should I
> remove encrypt.el from Gnus, or leave it in as a duplicate of the
> Emacs tree version?

I think encrypt.el should stay in Gnus too.  Most if not all files in
Gnus CVS also exist in Emacs CVS.  Future enhancements to encrypt.el
could be tested in Gnus CVS first.

Re: encrypt.el

[Reiner Steib]

On Wed, Dec 01 2004, Ted Zlatanov wrote:

> I need to clarify, however, how encrypt.el will coexist with the
> Gnus version.  Should I remove encrypt.el from Gnus, or leave it in
> as a duplicate of the Emacs tree version?

[I think you mean Gnus repository here, right?]

No Gnus is supposed to run on Emacs 21.1 (and up) and XEmacs 21.4 (and
up).  Wouldn't removing encrypt.el break running Gnus on versions
before Emacs 21.4?

Bye, Reiner.

[ Cc-ing Ding, trimming xemacs-beta ]
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: encrypt.el

[Ted Zlatanov]

On Wed, 01 Dec 2004, reinersteib+gmane@imap.cc wrote:

On Wed, Dec 01 2004, Ted Zlatanov wrote:
> 
>> I need to clarify, however, how encrypt.el will coexist with the
>> Gnus version.  Should I remove encrypt.el from Gnus, or leave it in
>> as a duplicate of the Emacs tree version?
> 
> [I think you mean Gnus repository here, right?]

Gnus CVS is synchronized with Emacs these days, so it would be both.

> No Gnus is supposed to run on Emacs 21.1 (and up) and XEmacs 21.4 (and
> up).  Wouldn't removing encrypt.el break running Gnus on versions
> before Emacs 21.4?

Yes, and I'll leave it in on yours and Simon Josefsson's advice.  So I
will only add encrypt.el to the Emacs lisp/ tree without removing it
from anywhere else.

I do wish that CVS supported symlinks :)

Ted

Re: encrypt.el

[Reiner Steib]

On Thu, Dec 02 2004, Ted Zlatanov wrote:

> On Wed, 01 Dec 2004, reinersteib+gmane@imap.cc wrote:
[...]
>> [I think you mean Gnus repository here, right?]
>
> Gnus CVS is synchronized with Emacs these days, so it would be both.

I think that Miles can do the syncing independent of the location, e.g.

  [v5-10]gnus/lisp/netrc.el <--> emacs/lisp/net/net/netrc.el

BTW, should `encrypt.el' go in the stable branch (v5-10), too?  Maybe
we already discussed this, but I forgot.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: encrypt.el

[Richard Stallman]

Let's not move any more files until after the coming release.

Re: encrypt.el

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Let's not move any more files until after the coming release.

We had a big discussion on which files to move a while back, and
Handa-san requested that we postponed any moves until the unicode
branch had been merged to the trunk.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: encrypt.el

[Ted Zlatanov]

I'll hold off on the encrypt.el migration until after the next Emacs
release, as requested.

Thanks for all the help
Ted

Re: encrypt.el

[Miles Bader]

> We had a big discussion on which files to move a while back, and
> Handa-san requested that we postponed any moves until the unicode
> branch had been merged to the trunk.

Is this still an issue now that merging into the unicode branch is done through
arch (which handles file moves with no problem)?

-Miles

Re: encrypt.el

[Kenichi Handa]

In article <fc339e4a04120717494c51693@mail.gmail.com>, Miles Bader <snogglethorpe@gmail.com> writes:

>>  We had a big discussion on which files to move a while back, and
>>  Handa-san requested that we postponed any moves until the unicode
>>  branch had been merged to the trunk.

> Is this still an issue now that merging into the unicode
> branch is done through arch (which handles file moves with
> no problem)?

I don't mind file moves as far as arch reflects them in
unicode branch correctly.

---
Ken'ichi HANDA
handa@m17n.org

Re: encrypt.el

[Richard Stallman]

    > Let's not move any more files until after the coming release.

    We had a big discussion on which files to move a while back, and
    Handa-san requested that we postponed any moves until the unicode
    branch had been merged to the trunk.

That makes two reasons not to do it now.
Thanks.