14,50d13
< 
< <a name="Issues to cover, if not addressed elsewhere">
< <h3>
< 4.1.  Issues to cover, if not addressed elsewhere
< </h3>
< </a>
< </p><p>
< <strong><em>NOTE:</em></strong> I'm leaning towards having at least what's
< calle the "bootstrap problem" just below dealt with in the "Platform
< Dependencies" subsection of Installation, rather that here.  The reason is that
< it's a user-visible issue.  If I've not said it yet, what goes here in
< development overview are <em>only</em> issues that are fully invisible to the
< user.
< <ul>
< <li>
< There's the bootstrap problem of where to store location of Cal Tool user
< directory.  Leave this up to the implementors, but suggest a fixed known file
< rather that modification of the application itself.  There are presumably
< platform-dependency issues here, e.g., in OS X, the "application itself" is
< acctually an entire directory hierarchy.  The thing is, I personally think it
< would be nice if the date stamp of what appears externally to the OS user as
< "the application itself" does not change every time the user changes the
< location of the Cal Tool user directory.
< <li>
< ... OK, rock on, dude.
< </ul><font color=black>
< OK, it seems like we've embarked in the above list on 17jul03 note (below) to
< discuss "Implementation Considerations", which is fine.  To get this fucker
< done, we can just dump here whatever we've thought of along the way, and be
< sure to keep separate requirements from suggestions and guidelines.  It might
< in fact be a great idea to keep this section completely <em>requirements
< free</em>, in that we can say that <em>everything</em> in this section is a
< suggestion, recommendation, or potentially useful observation for the
< implementors, but not a requirement.  To this end, I've put the requirment for
< the date stamp of the app not changing to non-functionals, and we can cite that
< requirement here in the lower-level implementation discussion.
< </p><p>