home *** CD-ROM | disk | FTP | other *** search
/ Peanuts NeXT Software Archives / Peanuts-2.iso / Developer / resources / classes / misckit / MiscKit.mbox / text0024.txt < prev    next >
Encoding:
Text File  |  1993-10-26  |  3.6 KB  |  78 lines
  1. Christopher Kane writes:
  2. >Setting up an analog to /usr/lib/NextStep/Resources, or some
  3. >related analog (/LocalLibrary/*, etc), to achieve some sharing,
  4. >and having Installer (a reasonable method) install the files in
  5. >these sort of locations is a nice idea, if you (as developer) have
  6. >(or Joe User has) the 'power' to write files into these areas.
  7. >Joe User (and developers) on a LAN administered by the organization
  8. >they're part of probably doesn't have write permission into these
  9. >areas.  Expecting that sysadmins would be happy to change this,
  10. >or would be accomodating to install things for users, is expecting
  11. >*way* too much.  Having your own NeXT on your desk (or being a
  12. >sysadmin) is swell, but there will be a good chunk of users (users
  13. >in education and corporate come to mind) that'd lose on such a
  14. >strategy.
  15.  
  16. Here's a proposal:
  17.  
  18. /usr/local/lib/MiscKit/Resources, which parallels
  19. /usr/lib/NextStep/Resources, as the directory for all auxiliary
  20. files associated with the MiscKit library.  The installation program
  21. places all the aux files there, and if it happens that it is
  22. implemented at the site as a link to somewhere else, it doesn't
  23. matter.  There should be subdirectories if necessary (bundles and
  24. nibs are directories anyway).
  25.  
  26. If a user is installing the kit in a home directory, then the
  27. directory should be ~/Unix/usr/lib/MiscKit/Resources, same reasons.
  28.  
  29. >Someone else wrote (sorry, I don't have the original article to
  30. >attribute this):
  31. >>As for the problem of auxiliary files for MiscKit, I'm in favor of
  32. >>something like Don proposed.  However, the proper place for bundles
  33. >>is /LocalApps or ~/Apps, not the *Library directories (NeXT says
  34. >>this).  Depending on the naming convention for the kit, it would
  35. >>probably be wise to have one bundle per prefix or something.
  36. >
  37. >Does the "bundles belong in *Apps" approach apply to all bundles,
  38. >or just WM inspector bundles or services?  I'm skeptical of the
  39. >former (and I can't locate anything that says this), but the later
  40. >two cases are documented.
  41. >
  42. >Preferences bundles have to be in ~/Library/Preferences,
  43. >/LocalLibrary/Preferences, /NextLibrary/Preferences, or
  44. >/NextApps/Preferences.app.  If there is a UI-type convention to
  45. >put all bundles in *Apps, NeXT has broken it itself.  (Wait a
  46. >minute.  What am I saying?!  Why do I sound surprised?!! :-))
  47. >But somehow, it just doesn't make sense.
  48.  
  49. That was my post, and all I can say is that everything I've seen
  50. and heard from NeXT about installing standalone bundles (unless
  51. designated for a special purpose like preferences bundles) says to
  52. put them in /LocalApps or ~/Apps.  Note that it is possible to have
  53. a completely general-purpose bundle that is loadable by _any_ app.
  54. Personally, I'm surprised that there are not more of these available;
  55. the possibilities are staggering, especially if bundles' code can
  56. be made shareable like shared libraries.  NeXT?
  57.  
  58. I'm guessing that the reason for putting them in /LocalApps or
  59. ~/Apps is that bundles are the same as apps, except they have no
  60. main entry point in the executable.  Our "special purpose" is to
  61. centralize all the MiscKit auxiliary files to simplify installation
  62. and maintenance, and that's good enough.
  63.  
  64. A personal feeling is to watch for bundles (or something very like
  65. them) to become increasingly important in the future, eventually
  66. even replacing apps as the basic unit of execution in NEXTSTEP.
  67. This is based on the direction I've heard NS4.x is headed, as well
  68. as some concepts that I came up with for our internal development
  69. that will prove interesting for the future of apps, at least ours.
  70.  
  71. Thanx,
  72. Michael
  73.  
  74. ---
  75. Michael_Pizolato@afs.com
  76. NeXTMail appreciated
  77.  
  78.