CVS update: tng/source/passdb

[Cole, Timothy D.]

-----Original Message-----
From: idra at samba.org [mailto:idra at samba.org]
Sent: Tuesday, January 08, 2002 11:15
To: tng-technical at lists.dcerpc.org; samba-technical at samba.org
Subject: Re: CVS update: tng/source/passdb

No it is not impractical isimply unneded as proved by lack of interest and
there's no monopoly (or do you call that of apache a monopoly over port 80
because when it is running it keeps the port 80 busy?, or sendmail with port
25? or any other server program??)

Perhaps I am remiss in my attempts to understand the situation, but I do not
believe this analogy is fully applicable.

I believe this hypothetical situation would be closer to the situation at
hand:

 - SMTP (among other protocols) may optionally be tunneled over HTTP

 - Microsoft servers offer both SMTP and HTTP on the same machine;
consequently:

 - Microsoft client and server software for both SMTP and HTTP is written
with the assumption (in places) that SMTP over HTTP would always be
availible

 - The established open-source project, "Apache" decided to focus on
web-serving via HTTP (including barebones SMTP support to make Microsoft
Internet Explorer happy) ... which makes sense, you can't humanly get it all
in one bite.

 - SMTP and HTTP were several orders of magnitude more complex, requiring
expert knowledge and precluding additional from-scratch re-implementations
within a reasonable timeframe ("Apache" took maybe 10 linear years to begin
with, and many more man-years)

 - The newer open-source project, "OpenMSMail" wanted to take the older
"Sendmail" codebase and offer a compatible replacement for Microsoft SMTP
services

 - "OpenMSMail" must offer SMTP on both port 25 and over HTTP to be
compatible with Microsoft software

Now, from here... one of the following must happen:

 * Users must run "OpenMSMail" and "Apache" on separate servers (or as
separate "virtual" servers on separate interfaces).  Multiple IPs per server
present problems with maintainence (harder than just installing an "RPM"),
and are often not compatible with corporate network policies.  The
incomplete (or out-of-date) HTTP and SMTP implementations on each side
preclude higher-level interoperability with Microsoft software which
expected both services from the same (apparent) host.

Open-source would fail to provide a viable alternative to Microsoft
services.  The relatively open infrastructure that permitted open source
would deteriorate from disuse in corporate environments.

This is the default.

Other possibilities:

 * "OpenMSMail" forks "Apache" to provide full HTTP and SMTP services.
"OpenMSMail" does not appear to have the manpower to do this, as most
availible manpower with sufficient knowledge/experience of HTTP is already
concentrated in the "Apache" project.

 * "Apache" provides a "plugin" (loadable .so) architecture to allow the
implementation of additional SMTP over HTTP features.  "OpenMSMail" and
other projects requiring SMTP over HTTP become partially dependent upon
"Apache" internals and must closely track its development.  This is not
totally unworkable, but it is difficult.  [ if the difficulties here are not
already apparent, consider why (in the real world) SWAT was not implemented
as "mod_swat" ]  Nonetheless, the main practical roadblock to compatibly
implementing MS-SMTP would be removed, provided the plugin architecture
exposed the right functionality.

 * Somebody (the "Apache" project would be the natural candidate) writes an
"HTTP multiplexer" which permits "Apache", "OpenMSMail" and other standalone
applications requiring an HTTP transport for whatever to collaborate in a
generalist way on the same server.  Again, the main practical roadblock to
implementing MS-SMTP and other services over HTTP is removed.

I am not certain I would term this situation a monopoly, but in the default
case above, "Apache"'s establishment and the relative importance of
web-serving over mail service in a corporate environment (if you had to pick
one in my hypothetical world) would make other projects using HTTP a very
difficult sell.

This only reflects my understanding of the situation.  Perhaps I am missing
something; I have not had time for Samba for a long time.

---

p.s. Back to the real world for a moment, it sounds to me (perhaps I am
wrong) as if the most recent iterations of Andrew's loadable pipe .so
proposal thing represent something of a middle ground (from a practical
perspective) between the third and fourth possibilites indicated above