Re: Licence issues for libESMTP (and Balsa) - long (was Re: NTLM authentication)

[Brian Stafford <brian stafford uklinux net>]

On Thu, 10 January 13:05 Matthias Andree wrote:
> On Thu, 10 Jan 2002, Brian Stafford wrote:

> > dlopen/sym/close are in the Single Unix Specification v2 (I don't know
> > about v1).  Presumably the portability issues will ease off in future.  (It
> > would be nice if they made it into Posix too.)
> 
> That may well be, but I still think that it will hurt people on desktops
> that run e. g. older versions of commercial unices.

Maybe, maybe not.  If dlopen is not available or horribly broken, it can 
always be stubbed out.  LibESMTP will only lose TLS support which is not as 
bad as it seems - SMTP and TLS do not mesh that well since it provides only 
per hop security.  If the message is to be protected S/MIME or PGP/MIME is the 
way to do it - and that is not a libESMTP issue.

Even so, with a properly defined module interface, the module could still be 
statically linked, licence issues permitting.  All that is needed are some 
stubs for dlopen/sym/close to return the right pointers to the module's data.

[snip]

> > I take the view that the dlopen/sym/close approach is the correct one,
> > since SUSv2 describes the interface and semantics.  Regarding portability,
> > there is always libltdl distributed with GNU libtool to fall back on if the
> > dlopen functions are not available.  An alternative fallback might be the
> > gmodule interface from glib.  However, my own feeling is that libltdl and
> 
> GNU libtool, or, its libltdl, reeks of bloat. I never used it myself,
> but I'd be surprised if it had a small footprint (GNU libc pulls around
> 1,500 symbols into a simple main(){(void)write(1, "hello!\n",7);}

libltdl is, surprisingly, a fairly thin wrapper for the platform's functions.  
It would be even thinner if it didn't have processing for the .la files.  I 
haven't been able to figure the reasoning for having .la files.

> > gmodule should provide the SUSv2 API rather than their own private APIs.
> 
> glib might get that API for v2.0, asking the developers may be
> worthwhile.

Don't confuse glib with glibc.  glib is the thing that provides a low level 
API used by gtk+ among other things.  glibc provides dlopen/sym/close.

[snip]

> Seriously, I didn't mean that suggestion as real feature request, and
> fetchmail indeed supports ODMR, I only find it strange that ETRN is in
> libESMTP in the first place, which - as you yourself said - is somehow
> the wrong direction of data flow.

Well, the ETRN code has experimental status only.  Other than being a feature 
request, writing the code exercised the design of the protocol engine 
regarding the ease of adding new protocol commands.  It wasn't hard to do, so 
I figure I got the protocol engine about right too.

--
BCS