Subject: Binary compatibility between c-client releases

From: Andrej Borsenkow <[email-masked]>
Date: Thu, 23 Jul 1998 12:29:12 +0400

To which extent are different c-client releases binary compatible? That
is, is it possible to build shared c-client library and simply replace
existing one? I have at least two reasons to ask:

  1. imapd + imap-util alone include 13 different programs. Add to this
Pine and possible
     "third-party" software (e.g. TkRat). Currently, with any bug-fix in
c-client it
     is necessary to recompile everything. But c-client code changes
probably more often than
     programs itself. It greately simpifies maintenance.

  2. These 13 programs statically compiled on i386-sni-sysv4 with
egcs-1.0.3 (-O2)
     take approximately 5MB (without Pine or anything else).

     The same programs on mips-sni-sysv4 compiled with shared c-client
(native compiler)
     take less than 1MB.

thank you for any hint

-- 
============================================================
Andrej Borsenkow 		Fax:   +7 (095) 796 99 20
SNI ITS Moscow			Tel:   +7 (095) 796 99 24

NERV:  borsenkow.msk		E-Mail: [email-masked]
============================================================

------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Thu, 23 Jul 1998 01:37:40 -0700 (PDT)

On Thu, 23 Jul 1998 12:29:12 +0400, Andrej Borsenkow wrote:
> existing one?

There were significant API changes between imap-3.6 and imap-4, and again
between imap-4 and imap-4.1.  imap-4.2 and imap-4.3.BETA have the same API as
imap-4.1.

I can not promise that imap-4.3.BETA won't have API changes; although it is
likely that future API changes will take the form of extensions and the days
of incompatible API changes are now over for good.

But, once again, "no promises".  ;-)

There are some factors that interfere with *me* supporting c-client as a
shared library:
 1) the general inconvenience and nuisance in the development cycle (I am
    perpetually in a development cycle....) of shared libraries.
 2) the fact that every system has its own incompatible way of doing shared
    libraries.  I don't want to do Linux-only or Solaris-only; if I do shared
    libraries I want to do it on a comprehensive basis for all platforms that
    allow shared libraries.
 3) the system that I use does not allow shared libraries other than what
    is provided by that vendor.  A certain well-known figure in the computer
    industry decreed that shared libraries were not for mere customers...
    Since I don't/can't use them on my own system, I am very uncomfortable
    about inflicting them on others.  I always am the first tester of new code
    and my personal mailbox is the first victim...  ;-)
 4) in the Pine binary distributions, we want to distribute completely self
    contained binaries without requiring external files.

In other words, I won't offer shared libraries at the current time; but I
encourage you (or anyone else who feels that it's important) to do it for your
own systems.  I would also give serious consideration to proposed code changes
that would make shared libraries easier, assuming there is no negative in
doing so.

With any luck, it should be just a matter of local patches to the c-client
Makefile.