From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general,gmane.emacs.devel Subject: Re: imap.el and nnimap.el [was Re: Build failure bzr trunk revno 103260] Date: Mon, 14 Feb 2011 14:52:25 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87y65ipcdy.fsf@lifelogs.com> References: <8762sn4fgh.fsf@lifelogs.com> <87tyg72wrl.fsf@lifelogs.com> <87hbc6vf69.fsf@lifelogs.com> <87sjvq4cyz.fsf@gnus.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1297716923 15884 80.91.229.12 (14 Feb 2011 20:55:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Feb 2011 20:55:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: ding@gnus.org Original-X-From: ding-owner+M25078@lists.math.uh.edu Mon Feb 14 21:55:19 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pp5S2-0006YP-V8 for ding-account@gmane.org; Mon, 14 Feb 2011 21:55:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Pp5Rv-0003lc-JP; Mon, 14 Feb 2011 14:55:11 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Pp5Rt-0003lE-Tg for ding@lists.math.uh.edu; Mon, 14 Feb 2011 14:55:09 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1Pp5Rp-00055w-G6 for ding@lists.math.uh.edu; Mon, 14 Feb 2011 14:55:09 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Pp5Ro-0001K3-P2 for ding@gnus.org; Mon, 14 Feb 2011 21:55:04 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Pp5Ro-0006MP-Mu for ding@gnus.org; Mon, 14 Feb 2011 21:55:04 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Feb 2011 21:55:04 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Feb 2011 21:55:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 31 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:cArRllRtu0/8F7i7VnMfIFc2DdA= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:76738 gmane.emacs.devel:136020 Archived-At: On Mon, 14 Feb 2011 11:45:24 -0800 Lars Ingebrigtsen wrote: LI> Ted Zlatanov 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