Tom Emerson wrote:
> Let's see here -- "sendmail" is looking for a full-blown DBMS with
> transaction & logging capability -- seems to me IMAGE comes to mind... ;)

Actually, sendmail doesn't need all that fancy capability.  It's just that some
of the Unix DB packages used to implement the aliases stuff have evolved into
full-blown DBMSes with the fancy stuff.

> Let me pose a big "why not?" here -- after all:
>
>   -- the DBMS is native to the platform, thus less dependancy on
> another "rough-fit" application [DBMS]
>   -- we already know how to program for this DBMS [and quite well, I might
> add :) ]
>   -- the "port" is to this platform, not the other way around -- I would
> maintain that a platform-specific version of a program should make the most
> of the resources available to that platform.

Porting is easiest when you just use the POSIX API on MPE.  When you have to
resort to calling intrinsics, things get much more complex to implement, and
then because you're using native, non-POSIX OS functionality, you have just
increased your maintenance burden when new releases of the ported software come
out.

>   -- I don't think the "structure" of the database will change [except
> perhaps with the next release of sendmail, but that would be "another port"
> anyway...] however capacity sizing might be an issue [but we have HP & 3rd
> party tools for that anyway...]

I've never had to understand the structure of the alias data once it has been
loaded into a database.  It's possible you might have row length issues that
would exceed the limits of TurboImage, but I'm just speculating.

> Of course, one "why not?" reason/rationalization might be that it would
> take a significant amount of effort to code the database calls "correctly"
> (efficiently?) in the first place...

Converting native calls for database X into native calls for database Y is
going to be a major effort no matter how you choose X and Y.  ;-)

Rather than hacking at the sendmail source code to do that, it would seem to me
to make more sense by trying to implement the Berkeley DB API on top of
TurboImage.  That way you wouldn't have to do major surgery on sendmail, and
you could reuse this API to make Unix DB applications work seemlessly (?) with
TurboImage instead.

Either way, this is major effort which doesn't really alter the goal of why
sendmail is being ported -- to provide bundled e-mail with the e3000.
--
[log in to unmask]
Remainder of .sig suppressed to conserve scarce California electrons...

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *