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

Bertram Ludaescher ludaesch at sdsc.edu
Wed Apr 7 09:26:44 PDT 2004


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



More information about the Kepler-dev mailing list