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

[Matt Jones]

All of the issues that Bertram and others are raising are a side effect 
of the artificial boundaries caused by trying to organize source code 
along project lines.  Within any software effort I have been involved 
with, the directory organization has always followed a funtional 
arrangement that closely follows the underlying software model.  I think 
the simplest approach to this is to group actors functionally within 
packages and provide credit to contributors in the source code of each 
file.  This allows 1) contributions to be easily identified, and 2) 
contributors from multipe projects to the same file, and 3) a sensical 
layout of code that makes it easy for new developers to find things in 
the tree because the tree follows the software model.  The more I watch 
this converation evolve, the more strongly I feel that we should 
organize along functional lines rather than project lines.  Of course, 
this requires more design work up front, but I think that is a good 
thing and will be positive for the project.

Cheers,
Matt

Xiaowen Xin wrote:
> Hi Bertram,
> 
> On Wed, 2004-04-07 at 08:30, 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.
> 
> 
> Yes.
> 
> 
>>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. 
> 
> 
> No, there would only be one copy of each file.  If SPA needs to use
> something created by GEON, we would need to replicate it in the NCSU
> repository, and import org.geon.* for example.
> 
> 
>>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!
> 
> 
> I think we should put that file in one of the projects.  Just pick one
> that contributed most to it or the one that originated the idea.  All
> authors' names will get listed in the file, and the other projects can
> import that code.
> 
> 
>>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?
> 
> 
> Yes, that was exactly my point that we can't figure out what's useful to
> others.  So a top-level util/ directory doesn't make sense.
> 
> I think actors should go under org.sdm.spa.* and utility files
> (non-actors, but methods that are required by several actors) should go
> under org.sdm.spa.util.*
> 
> 
>>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
> 
> 
> I would say joint files go under one project, with authors clearly
> listed in the file.
> 
> If we put joint files in a common directory like util/, then that's also
> confusing.  Because you could have a scenario where SPA creates a file,
> but GEON subsequently helps to modify it significantly.  This would now
> qualify as a joint file, but should we move it from org.sdm.spa to util?
> 
> What do you think?
> 
> Xiaowen
> 
> _______________________________________________
> kepler-dev mailing list
> kepler-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------