emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ted Zlatanov
Subject: Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260]
Date: Mon, 14 Feb 2011 14:52:25 -0600
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Mon, 14 Feb 2011 11:45:24 -0800 Lars Ingebrigtsen <address@hidden> wrote: 

LI> Ted Zlatanov <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]