Date: Mon, 26 Feb 90 16:31:31 PST
In-reply-to: "Your message of 26 Feb 90 16:10:16 PST"
Sender: Tim Diebert:PARC:xerox
Subject: Re: Disussion: DF Suites for Cedar
To: Kenneth A Pier:PARC:Xerox
Cc: Tim Diebert:PARC:xerox, PCedarImplementors^:PARC:Xerox, Shibata:HARC:Fuji Xerox
Reply-To: Tim Diebert:PARC:xerox

Ken,

I think that one of the major points to have CedarCommon in the first
place is missed by your comments. In point 2 you reference
"[PCedar2.0]<Top>Foo-Source.df" as the repository for the sources of
package Foo. If a Cedar(Chest)7.0 package must access PCedar2.0, the
entire purpose of CedarCommon is lost. When I proposed a SharedSources
directory to Willie Sue, I was in Japan lamenting the fact that
[PCedar2.0]<Top>Gargoyle-Suite.df referenced CedarChest7.0 for load and
install files (and sources). These files were unavailable in Japan due
to a very old copy of CedarChest7.0 on Magenta:PARC:Xerox because
CedarChest would not all fit on an XNS server. By putting the sources
on yet another directory, it becomes easier to distribute software to
our remote sites, since you either make a copy of PCedar and CedarCommon
or Cedar, CedarChest and CedarCommon. Not PCedar, Cedar, CedarChest and
CedarCommon.

I think that the simple rule needs to be:

 If I share any files between PCedar and Cedar(Chest) I will store those
files in CedarCommon and I will use the appropriate INCLUDES in my DFs.

If we don't use CedarCommon as a way to remove the interdependencies of
PCedar upon Cedar(Chest) and Cedar(Chest) upon PCedar, why use
CedarCommon at all?

Tim

Date: 27 Feb 90 11:31:29 PST
Sender: Kenneth A Pier:PARC:Xerox
Sender: Mike Spereitzer:PARC:Xerox
Subject: Re: Disussion: DF Suites for Cedar
To: PCedarImplementors^:PARC:Xerox
Reply-To: PCedarImplementors^:PARC:Xerox

I hope you are keeping in mind the fact that some of us have plans for
another revision of practice at some later time (perhaps for PCedar3.0).
With regards to your attempt to clarify and document current practice:

1. I agree.

2. I assume your use of [PCedar2.0] in this paragraph is a typo, and
that you really meant [CedarCommon2.0]. Further, I thought we agreed
earlier that we might not always want to use "-Source" for the common
part, but sometimes prefer "-Common"; certainly we don't want to require
that a shared package share ALL the sources.

I dislike the requirements here. It looks like some unnecessary
make-work for maintainers of shared packages. In particular, I see no
advantage to having both Foo.df and Foo-PrincOps.df. Current practice
for me and several others is to have all the DCedar stuff in Foo.df. It
looks like, in your proposal, Foo.df is analogous to Foo-Suite.df and
Foo-PrincOps.df is analogous to Foo-PCR.df and Foo-Sun4(O3).df. As I've
pointed out earlier, I think the -Suite DFs should be abolished from
PCedar; let's not introduce them into DCedar!

As far as I know, there have been at least two uses of the -PrincOps
suffix. The one that I think is most reasonable is not the one you
propose. The one I think is most reasonable is this:
[PCedar2.0]<Top>Foo-PrincOps.df describes a debugging version of a
package that has been compiled in DCedar from PCedar sources; the idea
is that you can run this package in DCedar and debug your PCedar source.
This was (is?) most common for clients of (clients of (clients of ...))
Viewers. I'm not sure whether Cirio is good enough to obviate this use.
You might try asking if anybody has any interest in keeping this option
available.

3. It would be good to enunciate the general principle, which is that
files go as "high" (that is, toward DFs with more uses) as they make
sense. This principle says that the .require and .command files appear
in the highest DF that's used only for PCedar; if you were to adopt my
suggestion for (2), this principle would say that the .load and .install
files go in Foo.df.

4. The most important gluing --- making sure consistent stuff is
transferred by BringOver and SModel --- is done by the -Suite DFs. In
fact, people willing to compile both optimized and unoptimized files at
the same time can just point MakeDo at the -Suite and forget about
special crocky commands.

5. There are a couple of issues here.

One is, how to determine which files of a DF should be public and which
should be private. The principle for CedarChest remains: export what a
user needs to run the package (not what any maintainer needs to
compile). I don't remember ever hearing a principle for Cedar packages,
since there's another mechanism for constructing bootfiles. I think the
public/private bit is not important for PCedar because of the way the
Commander works (users don't bind to a package with BringOver); we could
recommend that everything be private, just to establish order (I
wouldn't suggest REQUIRING that, however, because that's asking people
to do unimportant work). While we are free to make up rules for PCedar,
I don't think we're free to make up rules for CedarChest or Cedar --- SO
WE MUST CONTINUE FOLLOWING THE ESTABLISHED RULES (wrt public/private)
FOR CEDARCHEST (and Cedar, if any).

The other issue is how to glue things together. I suggest that to
remain as consistent as possible with current practice, PCedar
maintainers BringOver/SModel Foo-Suite.df and DCedar maintainers
BringOver/SModel Foo.df and DCedar users BringOver -p Foo.df. This
means that the only references are: Foo-Suite.df INCLUDEs everything
needed for maintainance of the PCedar variants, and Foo.df INCLUDEs
everything needed for maintainance and use of the DCedar variants. Note
that the shared DF is INCLUDEd by TWO other DFs --- I think this is
appropriate, since the shared stuff is being maintained for both worlds.
I think that, since the only PCedar variants now being maintained are
the -Sun4 and -Sun4O3 ones, the above principle says that Foo-Suite.df
INCLUDEs Foo-Source, Foo-PCR, Foo-Sun4, and Foo-Sun4O3 in the common
case (where most of the sources are shared in
[CedarCommon2.0]<Top>Foo-Source). I think the above principle also says
that Foo.DF INCLUDEs [CedarCommon2.0]<Top>Foo-Source.df.

It is my hope that some day we can abolish the use of -Suites, and have
every DF reference its parent by INCLUDE. Otherwise, with N variants of
a package, we need 2N DFs: for each variant, one (like Foo-Sun4) to
contain variant-specific stuff and another (like Foo-Suite) to INCLUDE
everything else you need.

6. We should coin some new terminology (Eduardo tried this earlier, and
I liked his suggestions; unfortunately, not only were his suggestions
ignored, but conflicting practice was adopted). When we have
[CedarChest7.0]<Top>Foo.df and [PCedar2.0]<Top>Foo-Sun4.df and
[PCedar2.0]<Top>Foo-Sun4O3.df, we need:

 A. A way to refer to the whole collection of DFs, or
(interchangeably?) what's described by all those DFs. I like "package
Foo".

 B. A way to refer to, for example, the -Sun4 variant. I like "the
-Sun4 variant". I dislike trying use "version" here ('cause it's used
so many other, different, places).

 C. A variant is a program and assorted other files. They are
controlled by a set of DFs: Foo-Source, Foo-PCR, and Foo-Sun4; one of
these (Foo-Sun4) is most specific to this variant. We need a way to
refer to the set of DFs and a different way to refer to the most
specific DF. I like "the -Sun4 DF path" and "the -Sun4.df". I think
Eduardo suggested "the Sun4 slice" for the set of DFs and/or the
variant.

Mike

Date: 27 Feb 90 12:22:56 PST
Sender: Kenneth A Pier:PARC:Xerox
Subject: Re: Disussion: DF Suites for Cedar
To: PCedarImplementors^:PARC:Xerox
Reply-To: PCedarImplementors^:PARC:Xerox

In reply to Mike Spreitzer's message which I forwarded this morning:


1. Good.

2. Correct. Use of [PCedar2.0] in this paragraph is a typo; I really meant [CedarCommon2.0]. I agree to the simpler use of Foo.df for everything in DCedar. We have only six instances of Foo-Princops.df in /PCedar2.0/top/ today, so it would be painless to change now. So revised point 2 reads:

A package Foo in Cedar or CedarChest is described simply by the DF file Foo.df, as before. If a Cedar or CedarChest package Foo shares files with PCedar, the sharing must use CedarCommon. The DCedar package must be described with a DF file Foo.df in Cedar or CedarChest that Includes [CedarCommon2.0]<Top>Foo-Source.df and/or [CedarCommon2.0]<Top>Foo-Common.df as needed. [Cedar(Chest)7.0]<Top>Foo.df contains all the unshared material for the DCedar package.

3. I agree.

4. So the correct way to Make a package is then MakeDo -df Foo-Suite.df on the PCedar side and MakeDo -df Foo.df on the DCedar side.

5. DFs in CedarCommon will need to EXPORT public files for users and not export files such as common sources which only maintainers need. Unshared DFs in PCedar can be private, with the understanding that current DFs can be left alone until it is convenient to remove EXPORT clauses.

I like "the Sun4 slice" for the set of DFs and/or the variant because it is already documented that way. "Package Foo" to refer to the whole collection of DFs, or (interchangeably?) what's described by all those DFs is OK with me.

Date: 01 Mar 90 11:48:18 PST
Sender: Jules Bloomenthal:PARC:xerox
Subject: DFSuitesDoc
To: Pier:PARC:Xerox
Reply-To: bloomenthal:PARC:Xerox

Ken,

Should this the document mention something about the necessary pseudo-server; for CedarCommon2.0? At the moment I can't read anything from /CedarCommon2.0, and I don't know sits associated server.

   Jules