Projects

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Projects

Richard Gaskin
There is a broad category of tools which could benefit from having some definition of a "project", a list of all UI stacks, libraries, externals, etc. that comprise a given product or system.

The types of tools that could use this information include installer makers, version control systems, code analyzers, and even marketing support.  If there were a common definition of a "project", such tools could be used interchangeably.

This raises a variety of questions:

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

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

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

I'm very interested in your feedback.


Reply | Threaded
Open this post in threaded view
|

Re: Projects

david bovill
2009/4/6 Richard Gaskin <[hidden email]>

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


I'd say a property of the stack - as this could also be implemented as a
getprop which reads a manifest (text file).

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


The main thing I need and have just started working on is dependencies  and
I am not sure if this is related directly to what you mean by project. I
want a script to be able to download resources usually stacks containing
libraries from the internet - allowing you to send out individual stacks -
and not whole environments?


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


What are the use cases you see - I guess I'm looking for more of the sort of
thing you get with project compilers that deal with dependencies - given the
text file (or stack with property) - a tool can download and form a complete
application? I think that would be very useful - though personally I would
want it for every stack and not just the mainstack for the app.


[Non-text portions of this message have been removed]

Reply | Threaded
Open this post in threaded view
|

Re: Projects

Alain Farmer
In reply to this post by Richard Gaskin

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


     
Reply | Threaded
Open this post in threaded view
|

Re: Projects

Hugh Senior-2
In reply to this post by Richard Gaskin
A simplistic answer might be "the components required to deliver the
outcome". Required hardware (such as external servers and their software,
data routing maps, supporting infrastructure etc) may be also important... A
'project' could frankly include anything and everything, so there has to be
a cut-off point. I would (tentatively) suggest that a 'project manifest'
comprises the stacks, externals and media resources required for the
application to function as expected.

/H


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: 11 April 2009 11:51
To: [hidden email]
Subject: [revInterop] Digest Number 100

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


Reply | Threaded
Open this post in threaded view
|

Re: Projects

mwieder
In reply to this post by Richard Gaskin
Richard-

Monday, April 6, 2009, 9:41:29 AM, you wrote:

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

Very useful, but I'm wondering if it might not be possible to
piggyback off the existing cRevStandaloneSettings propertyset of a
stack?

--
-Mark Wieder
 [hidden email]

--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Projects

mwieder
In reply to this post by Alain Farmer
Alain-

Friday, April 10, 2009, 12:55:02 PM, you wrote:

> 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.

Yes! Absolutely.

> 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.

I'm not sure that "containing" one-or-more stacks would work. Maybe
relative file paths to the various stacks and documents. The project
file or object could end up growing hugely otherwise. And relative
links would make it possible to copy the project directory to another
environment for work. I'm envisioning:

Project directory
-- Project file
-- Source directory
---- Mainstack
---- Auxiliary stacks
-- Documentation
---- project docs
---- todo list
---- bug tracking
-- Multimedia documents
-- PDF documents
-- Unit tests
-- Archived older versions
-- etc

I'd like to see version-control links to subversion. Someday.
And dependencies is the key operative word: the project file or object
should keep track of file dates and/or sizes so it can determine when
a project file has changed, and therefore the project is out of date.

--
-Mark Wieder
 [hidden email]

--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Projects

Robert Brenstein-2
On 12.04.09 at 20:58 -0700 Mark Wieder apparently wrote:

>I'm not sure that "containing" one-or-more stacks would work. Maybe
>relative file paths to the various stacks and documents. The project
>file or object could end up growing hugely otherwise. And relative
>links would make it possible to copy the project directory to another
>environment for work. I'm envisioning:
>
>Project directory
>-- Project file
>-- Source directory
>---- Mainstack
>---- Auxiliary stacks
>-- Documentation
>---- project docs
>---- todo list
>---- bug tracking
>-- Multimedia documents
>-- PDF documents
>-- Unit tests
>-- Archived older versions
>-- etc
>
>I'd like to see version-control links to subversion. Someday.
>And dependencies is the key operative word: the project file or object
>should keep track of file dates and/or sizes so it can determine when
>a project file has changed, and therefore the project is out of date.
>
>--
>-Mark Wieder
>  [hidden email]

Isn't this going into building plist-type structures from OSX?

Robert