> Paul Kinnucan
> Sent: Sunday, November 12, 2000 5:54 AM
> At 02:42 PM 11/11/00 -0600, you wrote:
> >I think there is a third "level" needed, in both the new
> configuration
> >scheme Paul is creating, and the changes Nic is doing to the current.
> >
> >The three "levels" of configuration needs form a
> hierarchy/inheritance:
> > 1) Global: Base default configuration all projects start
> with, including
> >across all users. Overrides JDE defaults.
> >
> > 2) Package: Per package/project settings. Overrides
> anything in Global.
> >
> > 3) Environment: Local user specific things for the
> machine's environment.
> >Overrides anything in Package.
> >
> >Only overrides are specified at each level, not everything
> is in each like
> >today's prj.el. (tangent: an enhancement idea I have
> desired but not looked
> >into yet is to simply have a customize list of JDE variables
> to not save in
> >prj.el, so that JDE config info updates to per machine
> special elisp files
> >aren't also needing repeated updating in the prj.el files).
> >
>
> I tried what you are suggesting about two years ago, when I was first
> updating the prj.el system to handle customized variables. In fact, my
> first implementation did exactly what you are suggesting. I
> soon discovered
> that partial prj.el files work fine if you never open more
> than one project
> during a session. However, if you do open more than one project, the
> settings of all the projects become intermixed as the partial
> prj.el files,
> with overlapping but nonidentical variable subsets, get
> loaded. Neither I
> nor the other people who discussed this issue could figure
> out, given the
> need for project context-switching, a way to have each prj.el
> not set ALL
> the JDE variables.
>
> I posted a detailed analysis of this problem in the list at the time.
> Perhaps you can find it in the archive.
Interesting problems encountered. Thanks for mentioning this.
> To reiterate, I do not think the prj.el system is a suitable
> foundation for
> the kinds of things you want to do. I'm sure that you can, to
> some extent,
> hack it to do what you want but I believe the end result will
> be fragile
> and difficult to understand and use. That is why I prefer to
> build another
> system designed from the beginning to support the kinds of
> features that
> teams of developers need.
I agree. When you, Paul, read my input, I hope you read it as requirements
ideas, and issues to solve with the "brave new world" you are beginning.
Also note that I appreciate Nic's work, as it may result in making the
current setup more useful rather quickly. This does not mean I do not look
forward to the new setup!
