🚀 go-pugleaf

In article <411@ut-emx.UUCP> bill@emx.UUCP (William H. Jefferys) writes:
>In article <7965@j.ms.uky.edu> steve@ms.uky.edu (Steve Ferry) writes:
>~
>~   I just bought a copy of Multifinder from my local dealer 
>~and I'm upset by the way it handles DA's. I use a Datadesk 
>~...
>
>More importantly, this behavior seems to me to be a failure of
>systems design on the part of Apple. In general, MF ought to
>behave in ways that are parallel to the way things work under the
>old finder.
>...
This is definitely true, when the parallels are clear and the benefits outweigh
the problems.  In this case neither is so.  The only benefit to having the
default be to open in the layer is to allow for easier use of parasite DAs.  It
seems as though the number of non-parasitic DAs is far greater than the
parasitic ones.  In addition many of the parasitic ones are used with only one
or a few applications (i.e. Spell Checkers for word processors, Click Art
Effects for MacPaint, etc.).  Therefore, the logical choice seemed to be
what currently exists:  normal open creates another layer, Font/DA moving a
parasitic DA into an application's resource file is the easiest for the app-
specific parasitic DAs.

This leaves the category of DAs that are parasitic but not app-specific.
Really, these should not be DAs at all, they should probably be INITs.  If they
need an interface then this should be a DA (which will have no problem at all
existing in its own layer) or better yet an application.  For a good example of
this, take a look at the Intermail elctronic mail system, which combines an
INIT and a DA.  The INIT allows for notification in any layer, but the DA
interface stays in the DA Handler layer.

The primary reason for keeping the DAs in a separate layer is that many
applications simply cannot handle having a DA in its memory partition.  This
is a very difficult (read impossible) job for developers who wish to do
comprehensive memory management.  There is simple no way to handle a DA since
it has arbitrary memory requirements at arbitrary times.  The only real
possibility is to increase the SIZE of every single application, since any
application might be subject to the memory requirements of the DA.
This would be a huge waste of memory, which is already a scarce resource.
Therefore, the only real solution is to separate the DA from the app.

There are also obvious benefits to separating the DAs.  For example a DA such
as the alarm clock will stay open even if the app that it was originally
opened from is quit.  Also, it is a great deal easier to keep track of a
DA window since it is grouped with all other DAs, rather than spliced into
app's window list.

Hopefully the developers that have created these DAs will soon have a
chance to switch to INITs.  Also, we hope to add support for inter-process
communication, so that these products could be written simply as apps.  This
supports the desired ultimate end, because the application model is clean and
easy to support (from the point of view of the developer and of Apple) while
the DA model is not.

Of course, if the need is great enough there are ways for us to better support
the non-app-specific parasitic DAs in the short run.  Why don't all of you
out there in net-land let us know how often you use such DAs?  The current
belief here is that they are not used that often.

>
>Apple, are you listening?
>
>Bill Jefferys

Yes, we're always listening.  Always.  Merry Christmas.

-Phil Goldman
Apple Computer