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

Edward A Lee eal at eecs.berkeley.edu
Wed Apr 7 08:50:34 PDT 2004


I really believe it makes better sense to organize libraries
by function rather than by project.  Note that it is easy to
create custom libraries in Vergil that cross-cut the directory
structure, so projects can still provide their own "branding"
in releases...

Edward


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

------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal




More information about the Kepler-dev mailing list