From: byer@adobe.com (Scott Byer)
Subject: Re: TDF/ANDF (long) (Was: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.)
Reply-To: byer@adobe.com (Scott Byer)
Organization: Adobe Systems Incorporated
Date: Fri, 20 Nov 1992 17:54:53 GMT


Playing friendly ;-) devil's advocate for a minute...

Steve Folkes writes

> For any given application there only needs to be one piece of TDF.
> This TDF can be installed and executed on any machine that has a
> TDF installer and provides an implementation of any APIs that the
> application needs.

Once installed, there would seem to be no space savings over a fat
binary.  Also, if I added a new architecture to the network being
served by the server, I would either have to have the TDF on the
server, or dig up the original install disks.  One is a space cost,
the other is almost as inconvenient as having to get a FatBinary
update.

> The single piece of TDF means that the size of distributable won't
> increase as support for new architectures is added (actually, it
> isn't necessary to add support for new architectures - it's there
> automatically).

I'm not so sure this is a worry for a while - CD-Rom will be the
standard distribution medium, I think, and space won't be a concern
for a few years.  Actually, CD-Roms being so cheap to master and
press, I don't see space for distribution ever being an issue again.

> I suspect that TDF applications are more likely to survive operating
> system upgrades without breaking. When writing an application with
> TDF, the APIs the application uses are specified in a portable
> manner (and only the public parts of the API are specified). This
> means that the TDF that is distributed should be portable to anything
> that implements the API. The TDF contains no part of the API
> implementation itself.

> Probably the biggest disadvantage of TDF for the user is the fact
> that installation takes longer than installing a binary (as you
> need to do a partial compilation). The time is typically 50-75% of
> the compilation time.  However as you would normally only need to
> do this once per architecture it is probably not too great a price
> to pay.

Actually, there seem to be several other possible disadvantages
over FatBinaries, some of which are of a pretty big concern.

First is, there are just too many variables involved.  There are
now an additional set of combinations my QA department has to go
through to verify the application.  Also, the application becomes
too reliant on the API being done correctly on all the expected
platforms - this is a lot of extra work and bugfinding for the QA
department.

Also, what about licensing restrictions?  How is the installer
limited to installing only the compilations for the platforms tested
for and purchased?

What sort of protection of information is there?  If too much
information is kept in the TDF format, it becomes far too easy for
my competitors to reverse-engineer that fancy new feature we just
created that was supposed to give us an edge for 12 months.

A biggie is that TDF will slow down the application cycle
tremendously.  It's added another step in the compile-test-debug
cycle.  I can't just go directly from C to binary now and go to
TDF first for the QA cycle, my developers have to go through the
TDF cycle, slowing them down.

I also find it very hard to believe TDFs will survive updates any
better.  With binaries, I can statically link in libraries I think
will be mucked with - and they'll always be mucked with.  There's
just too much potential that a library API will be tweaked in the
wrong way across a new OS release.  Is there a way I can force the
TDF to behave like a specific verision and statically link in
specific versions of libraries at install time?

TDFs seems like a neat idea, but an application developer has to
be somewhat paranoid about the concerns mentioned above, and unless
they can be address,  just don't see significant applications using
TDF.  It's a theory vs. practice thing, I think.

--
Scott Byer                             NeXTMail: byer@mv.us.adobe.com
Adobe Systems Incorporated               These are *my* opinions, and  
1585 Charleston Road, P.O. Box 7900        do not necessarily reflect
Mountain View, CA 94039-7900             the opinions of my employer.
---------------------------------------------------------------------
Newsgroups: comp.sys.next.advocacy