Subject: External files & allowable contributions

From: Charles Bennett <[email-masked]>
Date: Tue, 14 Sep 1993 11:27:09 -0400

> From: [email-masked] (Don Yacktman)
> Subject: Re:  External files & allowable contributions
> 

> Another possibility, one I hope to do with my gamekit:
> 

> Provide a directory in either ~/Library or /LocalLibrary called,
> say, "MiscKit" which contains any "extras", perhaps in  
subdirectories
> if you like.  Then, a developer using the kit can either provide
> their own custom version inside the app wrapper (to override) or
> use the standard .nib.  One advantage of this is that you only need
> to keep one copy in a given filesystem...
> 

We have (kind of ) be using /LocalDeveloper for the same purposes.
(We picked LocalDeveloper since it echos NextDeveloper

/LocalDeveloper---- Apps
		|___Documentation
		|___Examples
		|___Headers
		|___Library
		|___Palettes

Perhaps a variation on the two ideas would work..  

The thing I dislike about our "solution" is dealing with libraries
since you have to either mess with the makefile templates or always
modify your own makefile.preambles to get the path to the libraries  
included.  (Then again perhaps I'm just lazy  :-)  )

---

From: Marc Millier <[email-masked]>
Date: Tue, 14 Sep 1993 08:59:21 -0700

> modify your own makefile.preambles to get the path to the libraries included.
>  (Then again perhaps I'm just > lazy  :-)  )

Just my $.02 worth. 

We do a similar thing, but we extend it by modifying the Makefile.preamble and
postamble for Palettes so that a "ld -r" library and the headers are included
in the Palette wrapper.  We then have a shell script that symbolic links the 

library and header into our standard locations (/ITILibrary/lib and 

/ITILibrary/include).  Of course, we always replace Makefile.preamble to add
the -L and -I switches to include our Palette libs and headers.  Since we
(thus far) have not had to otherwise modify the .preamble and .postamble so
we always replace them in the project with our internal standard ones.

This same technique works for bundles.  The advantage (and disadvantage) of this
technique is you need drag the library for each palette/bundle you use into
your project, sometimes a pain when you forget...

-marc

---

From: Mike Ferris <[email-masked]>
Date: Tue, 14 Sep 1993 08:10:04 -0700

Hi,

> Provide a directory in either ~/Library or
> /LocalLibrary called, say, "MiscKit" which contains
> any "extras", perhaps in subdirectories if you like. 

> Then, a developer using the kit can either provide their
> own custom version inside the app wrapper (to override)
> or use the standard .nib.  One advantage of this is that you
> only need to keep one copy in a given filesystem...
> 

I would have to say that this is asking for trouble.  In my opinion  
an app should be as self-contained as possible.  For development  
having some common nibs in LocalLibrary might be OK, but for an  
end-user, it's only one more thing to go wrong, one more thing to  
inadvertantly delete.  Nib files aren't that big anyway.

____________________________________________________________
Mike Ferris                 You can't depend on your eyes
[email-masked]              when your imagination is out of
Rubicon Software            focus.
(510) 652-2039                                   -Mark Twain

---

From: [email-masked]
Date: Tue, 14 Sep 1993 12:14:42 -0400

>included.  (Then again perhaps I'm just lazy  :-)  )

We do a similar thing here.  Our structure is almost the same as
the above:

/LocalDeveloper/Apps
               /Examples
               /Headers
               /Images
               /Libraries
               /Makefiles
               /Palettes
               /Projects

In addition, /usr/local/lib is a link to /LocalDeveloper/Libraries
and /usr/local/include is a link to /LocalDeveloper/Headers.  Thus
both get searched by the compiler and linker with no modifications
to makefiles and no additional compiler/linker flags.

I also have a similar hierarchy in ~/Developer.  Also, ~/Unix/lib
is a link to ~/Developer/Libraries and ~/Unix/include is a link to
~/Developer/Headers.  To get the compiler and linker to look in
these directories, I created
~/Developer/Makefiles/app/MRPMakefile.preamble, which defines such
macros as OTHER_CFLAGS to add the appropriate directories to my
compiles.  Whenever I create a new project, I just include
MRPMakefile.preamble in the Makefile.preamble of the new project,
and it's usually the only change I have to make to the template
(I'm lazy too :-).

As for the problem of auxiliary files for MiscKit, I'm in favor of
something like Don proposed.  However, the proper place for bundles
is /LocalApps or ~/Apps, not the *Library directories (NeXT says
this).  Depending on the naming convention for the kit, it would
probably be wise to have one bundle per prefix or something.  For
example, if I contribute stuff that is generally named MRPwhatever,
I'd code it to look for MRP.bundle or something in the standard
location.  Someone else's stuff would use a different bundle.  This
prevents a massive MiscKit bundle.

The problem with the *Apps directories as the repository is that
they would get cluttered with lots of bundles.  *Library/MiscKit
is a way to hide the clutter, but it's non-standard.  Any ideas?

Thanx,
Michael

---
Michael Pizolato                         [email-masked]
Mu-I-Jin                                     NeXTMail appreciated
Anderson Financial Systems Inc.

---

From: [email-masked] (Don Yacktman)
Date: Tue, 14 Sep 1993 14:38:57 -0600

> probably be wise to have one bundle per prefix or something.

The reason I suggested the *Library areas is because this is a shared
resource, etc., etc.  I didn't realize NeXT wants this kind of thing
in the *Apps areas--it doesn't make a whole lot of sense to me.  In
particular, when you log in, the *Apps sections are searched for
executables, etc., and adding all these bundles would slow down
logins...I wonder what NeXT's reasoning was.  Well, there's a few
folks at NeXT who read this, maybe they could shed some light here. :-)

What I was thinking of with this suggestions is something along
the lines of how NEXTSTEP shares .nibs among apps.  There are
actual .nibs for things like the open/save/alert/font panels in,
I believe, /usr/lib/NextStep (the path is something like that).
Putting them in /LocalLibrary/MiscKit would mirror this fairly
closely.  Of course, if there aren't that many .nibs, and they are
all quite small, well then including them in every app begins to
make sense.  If you start including standard images, sounds, etc.,
though, a library of sorts would become more attractive.  Note that
you could easily set up an Installer script to install MiscKit apps
that would handle proper set up of the library files, so it doesn't
have to be any worse for the end user, really.

As to linking /usr/local/include to /LocalDeveloper/Headers and
/usr/local/lib to /LocalDeveloper/Libraries, I recommend this
approach, since it pretty much mirrors what NeXT has done.

Later,
-don

---

From: [email-masked]
Date: Tue, 14 Sep 1993 18:25:23 -0500

[email-masked] (Don Yacktman) writes:
> closely.
[and there has been other discussion of /LocalLibrary heirarchies,
 and related, which I'll not quote.....]

Setting up an analog to /usr/lib/NextStep/Resources, or some
related analog (/LocalLibrary/*, etc), to achieve some sharing,
and having Installer (a reasonable method) install the files
in these sort of locations is a nice idea, if you (as developer)
have (or Joe User has) the 'power' to write files into these
areas.  Joe User (and developers) on a LAN administered by the
organization they're part of probably doesn't have write
permission into these areas.  Expecting that sysadmins would be
happy to change this, or would be accomodating to install
things for users, is expecting *way* too much.  Having your own
NeXT on your desk (or being a sysadmin) is swell, but there will
be a good chunk of users (users in education and corporate come
to mind) that'd lose on such a strategy.

Someone else wrote (sorry, I don't have the original article to
> probably be wise to have one bundle per prefix or something.

Does the "bundles belong in *Apps" approach apply to all bundles,
or just WM inspector bundles or services?  I'm skeptical of the
former (and I can't locate anything that says this), but the later
two cases are documented.

Preferences bundles have to be in ~/Library/Preferences,
/LocalLibrary/Preferences, /NextLibrary/Preferences, or
/NextApps/Preferences.app.  If there is a UI-type convention to
put all bundles in *Apps, NeXT has broken it itself.  (Wait a minute.
What am I saying?!  Why do I sound surprised?!! :-))  But somehow,
it just doesn't make sense.

Christopher Kane
[email-masked]

---

From: [email-masked] (Don Yacktman)
Date: Tue, 14 Sep 1993 17:59:00 -0600

> [...Joe user can't write to /LocalLibrary...]

The solution is to either (1) make the installer script
recognize the problem and allow the user to install the
stuff in ~/Library instead...allowing the option to
abort and restart with proper permissions if necessary,
or (2) have two packages, one a general MiscKit library
and the other the app itself.  In the installation
instructions is tells the user to install in one of the
appropriate locations.  Two installation packages isn't
that difficult, and would be reasonable anyway since the
user can then upgrade either packages.  Dataphile is an
example of a multi-package distribution as is SoftPC.

I'm not sure that this issue is so important right now,
though.  There are several solutions, and which is best
will depend entirely upon how many resources would be
placed into the library.  If there's, say, three or four
nibs that take ~3-10k each, it would be just as good to
include them in the .app wrapper.  If there's sounds,
images, and many .nibs, then the library makes more sense.
Until we have a good idea what will be in the MiscKit
(beyond what's already there), either method is reasonable.

Let's make some decisions on basic issues like the
license, source code control, naming, etc. as well as
what various individuals would like to contribute.

Some offered contributions include enhancements to the
DAYTime class, Scott Anguish's ClockView (prelim. form
in the current release...), an IconWell, and I have a
simple Tree data structure I've used for various things.
Note that all the current offerings require no external
resources, making the above discussion rather moot.  The
closest you get is some IB palettes, which obviously belong
in /LocalDeveloper/Palettes in some way, shape, or form...

Later,
-don

---

From: [email-masked]
Date: Wed, 15 Sep 1993 09:05:45 -0400

Don Yacktman writes
>The solution is to either (1) make the installer script recognize
>the problem and allow the user to install the stuff in ~/Library
>instead...allowing the option to abort and restart with proper
>permissions if necessary, or (2) have two packages, one a general
>MiscKit library and the other the app itself.  In the installation
>instructions is tells the user to install in one of the appropriate
>locations.  Two installation packages isn't that difficult, and
>would be reasonable anyway since the user can then upgrade either
>packages.  Dataphile is an example of a multi-package distribution
>as is SoftPC.

Installations by root should default (overridably, is that a word?
:-) to central locations like /LocalLibrary.  Installations by
anyone else should default to somewhere in the user's home directory.
Any installation program should be able to handle both, either by
figuring out automatically where things should go, or by allowing
the user to specify, rejecting places where the user has no permission.

MiscKit should be viewed as it's own product, and so should have
it's own installation, separate from any app that uses it.  App
developers may have to distribute MiscKit packages in addition to
their apps, but the fact that there is control over the handling
of MiscKit files through the package and installation procedure
makes it worth the small amount of additional work involved for the
installer.

>I'm not sure that this issue is so important right now, though.
>There are several solutions, and which is best will depend entirely
>upon how many resources would be placed into the library.  If
>there's, say, three or four nibs that take ~3-10k each, it would
>be just as good to include them in the .app wrapper.  If there's
>sounds, images, and many .nibs, then the library makes more sense.
>Until we have a good idea what will be in the MiscKit (beyond
>what's already there), either method is reasonable.

The issue is important because it's a fundamental implementation
decision whether to hide _all_ the auxiliary resources that go with
the kit, so that the only access to them is through the kit's
classes, or not to hide them, so the developer has to know how to
get them into a project.  I'm strongly in favor of the former, for
encapsulation reasons, as well as some of the same control advantages
that a separate MiscKit package gives.  Auxiliary files are
implementation details, and MiscKit should be hiding them just like
objects hide code in classes.  If NeXT changed SavePanel to be a
panel created in code instead of using the nib in
/usr/lib/NextStep/Resources, it would make no difference to users
of that class.  MiscKit should try for the same level of encapsulation
and control.

Thanx,
Michael

---
[email-masked]
NeXTMail appreciated

---

From: [email-masked]
Date: Wed, 15 Sep 1993 08:48:11 -0400

Christopher Kane writes:
>and having Installer (a reasonable method) install the files in
>these sort of locations is a nice idea, if you (as developer) have
>(or Joe User has) the 'power' to write files into these areas.
>Joe User (and developers) on a LAN administered by the organization
>they're part of probably doesn't have write permission into these
>areas.  Expecting that sysadmins would be happy to change this,
>or would be accomodating to install things for users, is expecting
>*way* too much.  Having your own NeXT on your desk (or being a
>sysadmin) is swell, but there will be a good chunk of users (users
>in education and corporate come to mind) that'd lose on such a
>strategy.

Here's a proposal:

/usr/local/lib/MiscKit/Resources, which parallels
/usr/lib/NextStep/Resources, as the directory for all auxiliary
files associated with the MiscKit library.  The installation program
places all the aux files there, and if it happens that it is
implemented at the site as a link to somewhere else, it doesn't
matter.  There should be subdirectories if necessary (bundles and
nibs are directories anyway).

If a user is installing the kit in a home directory, then the
directory should be ~/Unix/usr/lib/MiscKit/Resources, same reasons.

>put all bundles in *Apps, NeXT has broken it itself.  (Wait a
>minute.  What am I saying?!  Why do I sound surprised?!! :-))
>But somehow, it just doesn't make sense.

That was my post, and all I can say is that everything I've seen
and heard from NeXT about installing standalone bundles (unless
designated for a special purpose like preferences bundles) says to
put them in /LocalApps or ~/Apps.  Note that it is possible to have
a completely general-purpose bundle that is loadable by _any_ app.
Personally, I'm surprised that there are not more of these available;
the possibilities are staggering, especially if bundles' code can
be made shareable like shared libraries.  NeXT?

I'm guessing that the reason for putting them in /LocalApps or
~/Apps is that bundles are the same as apps, except they have no
main entry point in the executable.  Our "special purpose" is to
centralize all the MiscKit auxiliary files to simplify installation
and maintenance, and that's good enough.

A personal feeling is to watch for bundles (or something very like
them) to become increasingly important in the future, eventually
even replacing apps as the basic unit of execution in NEXTSTEP.
This is based on the direction I've heard NS4.x is headed, as well
as some concepts that I came up with for our internal development
that will prove interesting for the future of apps, at least ours.

Thanx,
Michael

---
[email-masked]
NeXTMail appreciated

---

From: [email-masked] (Matthias Heubi)
Date: Wed, 15 Sep 1993 19:25:58 +0200

What about Revision Control. The user cannot be required to install the MiscKit  
himself/herself. So applications using the kit must provide for the installation  
of the kit, too.

If you now have several applications that use the kit, it's likeley that not all  
of them use the same revision. This means that installing an app could overwrite a  
more recent version of the kit in /LocalLibrary or wherever!

Of course, centralized resources are neat - but it has to be thought out very  
well.

Matthias
--
Matthias Heubi ([email-masked])
Interkantonales Technikum Rapperswil (ITR)
Signal Processing and Communications Lab

---

From: "Christian A. Ratliff" <[email-masked]>
Date: Wed, 15 Sep 1993 13:35:31 -0700

Also, what about the collision caused by two different applications requiring two
different revisions of the Kit? If you could garuntee that _every_ contribution to 
the Kit had a consistently backward-compatible interface and semantics then this
might not be a problem, however...

christian

--------
Christian Ratliff            \ clotho, atropos, lachesis, paraguay, uruguay,
<[email-masked]>          / leto, laba, vesta, hermes, prometheus, edi,
Sales Systems Administrator  \ indikos, grendel, argent, indikos, aardvark,
Cabletron Systems, Inc.      / cerebrus

---

From: Mike Ferris <[email-masked]>
Date: Wed, 15 Sep 1993 18:29:36 -0700

Hi,

I ahve been watching the discussion about keeping the miscKit stuff  
external to any app that uses it like next does for certain nibs...

I cannot urge strongly enough that this not be done!

Many people have been drawing parallels to how next does this.  The  
BIG difference is that when if buy NextStep, you have those nibs and  
such.  Therefore any app can safely use them.  However, as soon as  
someone who is not Next tries to do this, all of a sudden  
MyGreatApp.app cannot be sure that all the things it needs to run  
will be there.  The loyal fans of MyGreatApp.app will ftp the thing,  
unpack it, run it, and it will fail.  MyGreatApp.app is no longer  
stand-alone.  It won't run on any NextStep machine, but only on those  
with the MiscKit bundle/directroy/library/whatever.  This is bad.   
For programmers, this would probably be acceptable.  For users this  
would cause many many headaches.

This is basically the same argument for why Next doesn't let you  
build shared libraries.  Anyone but Next who built a shared library  
could never be sure that it was there when it came time to run their  
app that was linked againt it.  When Next builds a shared library it  
KNOWS that it will be on every machine that runs NextStep.

Please help to keep next apps self-contained.  Don't spread pieces of  
your app all over the file system.  Imagine someone's app that used  
four or five little 3rd party kits like the one that's starting here.   
To use the app, the user would have to know to download not only the  
app itself but four or five other packages.  It's no good to package  
all those packages in with your distribution because then you defeat  
your own goal of reducing the size of the app where it counts the  
most (ie over the net).

I think the bit of extra space needed in each app will be dwarfed by  
the extra hassle needed to install these smaller apps.

____________________________________________________________
Mike Ferris                 Whenever you find that you are
[email-masked]              on the side of the majority,
Rubicon Software            it is time to reform.
(510) 652-2039                           -Mark Twain