Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Ted Zlatanov]

On Sun, 13 Feb 2011 22:00:11 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
GM> Also, don't files usually go to obsolete/ before being deleted
GM> altogether?
>> 
>> I don't see the point, considering it's so trivial to bring them back.

GM> It's for the benefit of people using foo.el in external packages, so
GM> that libraries don't just disappear from one Emacs release to the next.

Are there special warning when you use obsolete things?  `make-obsolete'
is on a finer level, but it's safe to assume that if something is in an
obsolete/ directory then everything inside should be obsoleted as well.

GM> On a related note, if nnimap.el is supposed to replace imap.el (?), then
GM> I think it is problem that the former has so many (Gnus) dependencies.
GM> Loading imap.el loads 1 file. Loading nnimap.el loads 57.

Gnus itself needs imap.el only in one place (mail-source.el) so I
propose we move imap.el to Emacs and out of Gnus when and if that
dependency is removed.  It's a general-purpose library anyway.

Ted

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Gnus itself needs imap.el only in one place (mail-source.el) so I
> propose we move imap.el to Emacs and out of Gnus when and if that
> dependency is removed.  It's a general-purpose library anyway.

I wonder whether it might make some sense to re-separate out some of the
more basic IMAP stuff from nnimap.el again.  nnimap.el slurped in all
the protocol-specific stuff from imap.el so that it could implement what
Gnus needed more efficiently, but there isn't really much reason why,
say, the login functions (and related) could be separated out again.

Then non-Gnus packages could just use this new stripped-down basic IMAP
library.  I think, basically, what most useful is the login functions
and a simple `imap-command' function, and the rest would be application
specific.

I've had a peek at the relevant nnimap and mail-source functions, and it
seems like it should be doable in a pretty clean fashion.

However, if the new basic IMAP library is called imap.el, then this
would still break third-party applications.

Thoughts?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Thoughts?

(The current imap.el is 3K lines.  The proposed minimal new imap.el
would be about 2-300 lines, which would be refactored out from
nnimap.el.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Ted Zlatanov]

On Mon, 14 Feb 2011 11:45:24 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Gnus itself needs imap.el only in one place (mail-source.el) so I
>> propose we move imap.el to Emacs and out of Gnus when and if that
>> dependency is removed.  It's a general-purpose library anyway.

LI> I wonder whether it might make some sense to re-separate out some of the
LI> more basic IMAP stuff from nnimap.el again.  nnimap.el slurped in all
LI> the protocol-specific stuff from imap.el so that it could implement what
LI> Gnus needed more efficiently, but there isn't really much reason why,
LI> say, the login functions (and related) could be separated out again.

LI> Then non-Gnus packages could just use this new stripped-down basic IMAP
LI> library.  I think, basically, what most useful is the login functions
LI> and a simple `imap-command' function, and the rest would be application
LI> specific.

LI> I've had a peek at the relevant nnimap and mail-source functions, and it
LI> seems like it should be doable in a pretty clean fashion.

LI> However, if the new basic IMAP library is called imap.el, then this
LI> would still break third-party applications.

Considering the work that went into nnimap.el, I agree some of it should
be thrown back into imap.el.  I guess you can try to provide backwards
compatibility, but it's not unprecedented to break the API in order to
get better functionality.  We can fix the stuff in Emacs that uses
imap.el and I doubt there's much third-party code using imap.el.

Ted

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> We can fix the stuff in Emacs that uses imap.el and I doubt there's
> much third-party code using imap.el.

Yeah, there may not be much, but perhaps stuff like Mew and VM uses it?
I don't know.

The built-in stuff that uses imap.el now is mail-source.el,
imap-hash.el and url-imap.el, according to Grep.  I'm not sure
url-imap.el is useful...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Ted Zlatanov]

On Mon, 14 Feb 2011 13:13:26 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> We can fix the stuff in Emacs that uses imap.el and I doubt there's
>> much third-party code using imap.el.

LI> Yeah, there may not be much, but perhaps stuff like Mew and VM uses it?
LI> I don't know.

LI> The built-in stuff that uses imap.el now is mail-source.el,
LI> imap-hash.el and url-imap.el, according to Grep.  I'm not sure
LI> url-imap.el is useful...

imap-hash.el is gone.  I think url-imap.el should be removed too, no one
is using it AFAIK.

Ted

Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> imap-hash.el is gone.  I think url-imap.el should be removed too, no one
> is using it AFAIK.

So the only in-tree user would be mail-source.el?  I think it might
still be worth separating out the bits needed (login/send-command) from
nnimap.el and put them in imap.el.

Unless anybody has any objections, I'll take a whack at doing so.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: imap.el and nnimap.el

[Glenn Morris]

Ted Zlatanov wrote:

> Are there special warning when you use obsolete things?

Yes, you get a warning when loading something from obsolete/.

> Gnus itself needs imap.el only in one place (mail-source.el) so I
> propose we move imap.el to Emacs and out of Gnus when and if that
> dependency is removed.  It's a general-purpose library anyway.

Sounds good to me. It's already in the net/ directory in Emacs, so from
the Emacs side there would be nothing to do. Just stop syncing it
to/from Gnus I guess.

Re: imap.el and nnimap.el

[Ted Zlatanov]

On Mon, 14 Feb 2011 15:17:22 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
>> Are there special warning when you use obsolete things?

GM> Yes, you get a warning when loading something from obsolete/.

Great, I had never used it :)

>> Gnus itself needs imap.el only in one place (mail-source.el) so I
>> propose we move imap.el to Emacs and out of Gnus when and if that
>> dependency is removed.  It's a general-purpose library anyway.

GM> Sounds good to me. It's already in the net/ directory in Emacs, so from
GM> the Emacs side there would be nothing to do. Just stop syncing it
GM> to/from Gnus I guess.

OK.  Thanks for your help.

Ted