https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=imap&componen... imap has been a total disaster in the past, and now we provide both dovecot and cyrus-imapd as robust alternatives. Since FC2, imap was stripped down to the "c-client" library with no server functionality. The only reason we keep libc-client, the library portion of imap, is so php-imap can build.
But why do we keep php-imap? NOTHING we ship uses it. squirrelmail long ago decided php-imap was unreliable and made their own implementation.
Our forced attempts to get rid of imap in FC2 were done in a confusing manner which remains both a support burden for us, and a huge point of frustration to users. [1] To make matters worse, 'libc-client' is a confusing name which is too similar to 'glibc', and meaningless to all developers.
Is this really worth more years of headache? Here are two proposals to deal with this.
Proposed Option #1: Rename libc-client to imap-libs =================================================== Bug #120873 outlines a workable alternative where * Package name is no longer misleading. * Installed in such a way to not conflict in files or deps with imap. * imap in Extras, completely unsupported by Red Hat.
Pros: Reduced support burden on us as we wont have many more stupid reports [1] from foolish users complaining that we've taken away their ability to use an insecure, buggy and slow mail server. Cons: We still would have responsibility of php-imap, which very few people use.
Proposed Option #2: Get rid of imap/libc-client completely ========================================================== * Remove imap and libc-client from all future distributions. * imap in Extras, completely unsupported by Red Hat.
Pros: No support burden for us. Foolish users can use it if they really wish. Cons: Difficult (but not impossible) to build php-imap Not our problem. Extras can provide this.
I personally would much prefer Option #2 because it reduces the support burden on Red Hat, for software that NONE of us care about. Any other opinions?
Warren Togami wtogami@redhat.com
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132928 Some guy complains about imap conflicting with libc-client "for no reason".
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132933 The same guy realizes imap sucks, and says dovecot should Obsolete imap. I point at Bug #120678 below as an example of why this is a bad idea.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120678 libc-client conflicts with cyrus-imapd (Earlier failed attempt to forcefully remove imap)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123580 Confusion due to php-imap...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120873 Rename libc-client to imap-libs. This or removal of libc-client are our best options.
--On Sunday, September 19, 2004 6:34 PM -1000 Warren Togami wtogami@redhat.com wrote:
Proposed Option #1: Rename libc-client to imap-libs
Any reason not to call it uwimap-libs? Why should it get premier naming as implementor of IMAP? (I realize it's a reference implementation of the protocol by the protocol's author, but we don't call BIND "dns".)
On Sun, Sep 19, 2004 at 09:58:04PM -0700, Kenneth Porter wrote:
Proposed Option #1: Rename libc-client to imap-libs
Any reason not to call it uwimap-libs? Why should it get premier naming as implementor of IMAP? (I realize it's a reference implementation of the protocol by the protocol's author, but we don't call BIND "dns".)
we call Apache "httpd". :)
On Mon, 2004-09-20 at 01:02 -0400, Matthew Miller wrote:
On Sun, Sep 19, 2004 at 09:58:04PM -0700, Kenneth Porter wrote:
Proposed Option #1: Rename libc-client to imap-libs
Any reason not to call it uwimap-libs? Why should it get premier naming as implementor of IMAP? (I realize it's a reference implementation of the protocol by the protocol's author, but we don't call BIND "dns".)
we call Apache "httpd". :)
Yes. But calling that 'apache-httpd' wouldn't cause people to run screaming from the building instead of actually _using_ it.
Whereas calling this 'uwimap-libs' instead of just 'imap-libs' probably _would_ have that effect. Which is probably a good thing for all concerned.
Kenneth Porter wrote:
Any reason not to call it uwimap-libs? Why should it get premier naming as implementor of IMAP? (I realize it's a reference implementation of the protocol by the protocol's author, but we don't call BIND "dns".)
My recollection is that "c-client" was named that to distinguish it from the *real* IMAP client reference implementation... which was written in Common Lisp. (Yep, IMAP is that old. (And as broken now as then.))
On Mon, 2004-09-20 at 01:30, Jamie Zawinski wrote:
[snip]
My recollection is that "c-client" was named that to distinguish it from the *real* IMAP client reference implementation... which was written in Common Lisp. (Yep, IMAP is that old. (And as broken now as then.))
Awe, man! I love reading your rants, but, at the risk of this running way off topic, what, pray tell, is wrong with IMAP? I've been becoming more and more of an advocate for IMAP, but I've got to admit that since I don't do a lot of programming these days, I don't know the ins and outs of it the way a programmer would.
On Mon, 2004-09-20 at 09:18 -0400, Paul Iadonisi wrote:
what, pray tell, is wrong with IMAP?
Mostly the caching semantics, I'd imagine. Some people really hate the fact that you can't edit stuff stored on IMAP without changing the UID, and you can't change the UID without also changing the position in the folder.
More people hate the fact that you have to re-fetch _all_ flags when you re-SELECT a folder, but the CONDSTORE stuff ought to fix that and make disconnected operation a little saner.
I suspect more people hate IMAP due to idiocy in IMAP clients and servers rather than problems with IMAP itself. My main problem, for example, is the way that Evolution will insist on issuing STATUS on all of my hundreds of folders, even the archive folders which are marked inactive, sometimes with a RTT of about three seconds per folder, before it'll actually bother to fetch the mail I just clicked on. But that's not strictly an IMAP problem. Neither is the fact that Evolution will spend ages fetching multi-megabyte attachments over my ISDN line, just in order to run 'file' on them to see what they are, before displaying the text/plain part at the beginning which would have told me I didn't want to bother downloading it :)
Sometimes I start up pine just to read my email while Evolution is doing its thing ;)
Kenneth Porter wrote:
--On Sunday, September 19, 2004 6:34 PM -1000 Warren Togami wtogami@redhat.com wrote:
Proposed Option #1: Rename libc-client to imap-libs
Any reason not to call it uwimap-libs? Why should it get premier naming as implementor of IMAP? (I realize it's a reference implementation of the protocol by the protocol's author, but we don't call BIND "dns".)
Possibly some legacy apps expect it to be named imap (which is what it has historically been named). Besides, IMO, packages should be called by their upstream name/tarball whenever possible, unless there is good reason to do otherwise. Recent examples raised (including yours) validates this: apache: As of 2.0, it's tarball is httpd (and for licensing reasons too ,I believe, Fedora Core can't use the name "apache"). bind: bind is and always has been called "bind".
If there is confusion over the name, then I'd be inclined to name it uw-imap possibly.
-- Rex
Rex Dieter wrote:
Possibly some legacy apps expect it to be named imap (which is what it has historically been named). Besides, IMO, packages should be called by their upstream name/tarball whenever possible, unless there is good reason to do otherwise. Recent examples raised (including yours) validates this:
I would agree that packages should be called their upstream name, but this should not be an absolute rule.
But if some "legacy apps expect it to be named imap", then that is horribly broken and stupid. Except for certain special cases, you should always try to dep on specific versioned libraries (which RPM tries to do automatically) and not the *package* name. Nobody suggested renaming the installed files.
imap-libs may very well be called uw-imap-libs just to be perfectly clear. It wouldn't hurt anything.
Warren Togami wtogami@redhat.com
On Sun, Sep 19, 2004 at 06:34:06PM -1000, Warren Togami wrote:
Is this really worth more years of headache? Here are two proposals to deal with this.
I don't think there is strong enough motivation to rename the packages. If Fedora Extras wishes to maintain an "imap" package then they can do so without needing to rename libc-client, modulo bug #132928. So I've built a libc-client package without the "Conflicts: imap" to fix that bug.
joe
Joe Orton wrote:
On Sun, Sep 19, 2004 at 06:34:06PM -1000, Warren Togami wrote:
Is this really worth more years of headache? Here are two proposals to deal with this.
I don't think there is strong enough motivation to rename the packages. If Fedora Extras wishes to maintain an "imap" package then they can do so without needing to rename libc-client, modulo bug #132928. So I've built a libc-client package without the "Conflicts: imap" to fix that bug.
I still maintain that "libc-client" is a horrible name for the package, but this is technically acceptable at least.
Warren Togami wtogami@redhat.com
On Mon, Sep 20, 2004 at 02:45:47AM -1000, Warren Togami wrote:
Joe Orton wrote:
On Sun, Sep 19, 2004 at 06:34:06PM -1000, Warren Togami wrote:
Is this really worth more years of headache? Here are two proposals to deal with this.
I don't think there is strong enough motivation to rename the packages. If Fedora Extras wishes to maintain an "imap" package then they can do so without needing to rename libc-client, modulo bug #132928. So I've built a libc-client package without the "Conflicts: imap" to fix that bug.
I still maintain that "libc-client" is a horrible name for the package, but this is technically acceptable at least.
Yes, it would be for almost every package in Fedora. Maybe we could rename every package to libc-client-xxx, the kernel to libc-server-yyy, and glibc to libc,the?...
libsomething is a common name, why not change to libimap?
Regards, Luciano
On Sun, 19 Sep 2004, Warren Togami wrote:
But why do we keep php-imap? NOTHING we ship uses it. squirrelmail long ago decided php-imap was unreliable and made their own implementation.
Our forced attempts to get rid of imap in FC2 were done in a confusing manner which remains both a support burden for us, and a huge point of frustration to users. [1] To make matters worse, 'libc-client' is a confusing name which is too similar to 'glibc', and meaningless to all developers.
Is this really worth more years of headache? Here are two proposals to deal with this.
As a 'user' of c-lib (via PINE, not shipped in FC), I'd say the uwimap-libs makes most sense. Indeed, remove it all together.
As an aside, is there any /decent/ C IMAP client library out there?
regards,
-
David Woodhouse -
Jamie Zawinski -
Joe Orton -
Kenneth Porter -
Luciano Miguel Ferreira Rocha -
Matthew Miller -
Paul Iadonisi -
Paul Jakma -
Rex Dieter -
Warren Togami