[SDM-SPA] Re: [kepler-dev] moving edu.ncsu to org.sdm.spa

[Xiaowen Xin]

Hi Bertram,

With reference to joint files, please see my response to your email
about it.

It would basically go under one of the projects--the one that originated
the file, or contributed most to it.

Xiaowen

On Wed, 2004-04-07 at 09:26, Bertram Ludaescher wrote:
> Edward:
> 
> I agree. 
> 
> However Kepler/SPA is pushing (i) a  clean-up of the directory
> structure which (ii) includes a reorganization by project of many
> parts.
> 
> I think (i) is really usefully, but I'm not sure where (ii) will take
> us. It seems to discourage actual cross-project development. As a
> developer working with others across projects I wouldn't know where to 
> put the joint code.
> 
> Xiaowen: where do the joint GEON/SPA actors go?
> 
> Bertram
> 
> >>>>> "EAL" == Edward A Lee <eal at eecs.berkeley.edu> writes:
> EAL> 
> EAL> I really believe it makes better sense to organize libraries
> EAL> by function rather than by project.  Note that it is easy to
> EAL> create custom libraries in Vergil that cross-cut the directory
> EAL> structure, so projects can still provide their own "branding"
> EAL> in releases...
> EAL> 
> EAL> Edward
> EAL> 
> EAL> 
> EAL> At 08:30 AM 4/7/2004 -0700, Bertram Ludaescher wrote:
> >> >>>>> "XX" == Xiaowen Xin <xin2 at llnl.gov> writes:
> >> ...
> XX> src/org/geon/OpenDBConnection.java, which is the only non-spa file I
> XX> could find that uses the code in util/.  Would it be okay for me to move
> XX> what's now in src/util into org/sdm/spa/util/?  Alternatively, we could
> XX> move those two files into org/geon/util/.
> >> 
> >> This "projectisation" gets tricky it seems.
> >> I think we shouldn't overdue it, but leave it to folks in the trenches
> >> to figure out the details for now.
> >> 
> >> But if we do organization by project (which as we see creates some
> >> interesting issues), then we shouldn't move GEON actors under SPA --
> >> util or not. It should be somewhere under GEON.
> >> 
> >> Also for n projects will we have 2^n subdirectories for all possible
> >> combinations? Where is the browserUI actor now? I think it's at least
> >> SPA&GEON. Maybe a subsequent version will be SPA&GEON&SEEK or
> >> SPA&GEON&Ptolemy, or of course SPA&GEON&PTOLEMY&SEEK.
> >> 
> XX> The reason for this is that since we're already dividing up most of the
> XX> source files by organization, we should just divide it all up by
> XX> organization.
> >> 
> >> What do we do with stuff that is authored by multiple authors (like
> >> browserUI)? I really want to understand how that works!
> >> 
> XX> I think the reason people wanted a util/ directory is so
> XX> that it would be a place to put code that would be useful for all
> XX> projects.
> XX> However, this criteria is hard to determine because most of
> XX> the code from one project could potentially be useful in the other
> XX> projects.  So I think having a util/ directory as a subdirectory of the
> XX> projects makes more sense.
> >> 
> >> I don't understand how this solves the problem. How would Efrat (GEON)
> >> know whether actors X,Y,Z she is developing are "util" (and thus
> >> potentially useful for others) or not?
> >> Should she spend cycles on figuring out what might be useful? I guess
> >> the database access actor will be, but what about the point in
> >> polygon?
> >> 
> >> I claim that fundamentally one CANNOT know what will be useful to
> >> others or not. By default everything could be useful, right?
> >> 
> >> 
> XX> If SPA needed to use something from GEON, we
> XX> could import org.geon.*; or org.geon.util.* as an example.  The
> >> 
> >> yes, that makes sense.
> >> 
> XX> distinction here between org.sdm.spa.* and org.sdm.spa.util.* is that
> XX> util.* contains non-actor utility code, while all the actors go into
> XX> org.sdm.spa.*.
> XX> 
> XX> I hope that made sense :)
> >> 
> >> yes, if you just want to split between non-actor code and actor code, then 
> >> the
> >> distinction between util and non-util seems reasonable.
> >> 
> >> So do I understand the proposal right that each project would have two
> >> subdirectories say
> >> 
> >> .../geon/util and
> >> .../geon/actors  ?
> >> 
> >> (only that the actors you didn't have as a separate subdir so far)
> >> 
> >> Still a major problem with this organization by project remains:
> >> How do you deal with joint development, even at the file level
> >> (actors, directors etc)? This is precisely what we want to encourage
> >> in Kepler. Where do these things go?
> >> 
> >> Bertram
> >> 
> >> 
> >> 
> >> 
> >> 
> XX> 
> XX> Xiaowen
> XX> 
> XX> _______________________________________________
> XX> kepler-dev mailing list
> XX> kepler-dev at ecoinformatics.org
> XX> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
> >> _______________________________________________
> >> kepler-dev mailing list
> >> kepler-dev at ecoinformatics.org
> >> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
> EAL> 
> EAL> ------------
> EAL> Edward A. Lee, Professor
> EAL> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
> EAL> phone: 510-642-0455, fax: 510-642-2739
> EAL> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal