Hi Richard Gaskin and RevInterop crowd, :)

> If there were a common definition of a "project",
> such tools could be used interchangeably.

Indeed! I wholeheartedly agree. There is strength in unity! :-)

> 1. Should a "project" be defined as a property of the
> mainstack for an app, or should it be a separate file?

This may or may not be useful to y'all, but in my opinion a PROJECT has a [much]
BROADER SCOPE than just a stack. A "project" should be a container that contains
one-or-more stacks ; as well as other files, project manage stuff, etc. Even
various versions of the "project" in-question, e.g. its entire history,
relationships with other documents, etc, etc.

It goes without saying that all or any subset of the above would not FIT into
ONE property! I therefore suggest that a "PROJECT" be defined as an object,
specifically a container, that contains one-or-more stacks +etc.

The fact that a stack belongs to a project could, of course, be encoded as a
property of the stack: e.g. the project of stack myStackRef

> 2. What info should be included
> in the definition for a "project"?

VERY-good question, Richard. :)

> 3. Is this actually useful,
> or could there be some other
> way of dealing with multi-file
> deployments that may be quite
> different?

Good question, Richard. Btw, I applaud your 'scholarly' approach of not
overlooking what may have already been done. Not "re-inventing the wheel" as it
were.

> I'm very interested in your feedback.

I now recede back into the obscurity of mute observation, ;-)

Alain