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

[Bertram Ludaescher]

>>>>> "XX" == Xiaowen Xin <xin2 at llnl.gov> writes:
..
>> 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> 
XX> No, there would only be one copy of each file.  If SPA needs to use
XX> something created by GEON, we would need to replicate it in the NCSU
XX> repository, and import org.geon.* for example.
XX> 
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> 
XX> I think we should put that file in one of the projects.  Just pick one
XX> that contributed most to it or the one that originated the idea.  All
XX> authors' names will get listed in the file, and the other projects can
XX> import that code.

Xiaowen: 
I don't feel comfortable with moving, say browserUI either under GEON
or under SPA. In either case the organization seems to imly that GEON
or SPA own this actor which is untrue.

The actor has been build in collaboration. It should be somewhere
under Kepler, yes, but neither under GEON nor SPA alone.

I guess we need a place for "truly collaborative" code and that would
be somewhere "neutral", i.e., under Kepler not under SPA or
GEON. That's where the code should reside IMHO.

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> 
XX> Yes, that was exactly my point that we can't figure out what's useful to
XX> others.  So a top-level util/ directory doesn't make sense.

Hmm.. I think just the opposite. Why would a Kepler member dig through 
subdirectors of project oriented folders to find what's there instead
of looking at a shared Kepler/util directory?

(some might call this "plain confusing" ;-)

XX> I think actors should go under org.sdm.spa.* and utility files
XX> (non-actors, but methods that are required by several actors) should go
XX> under org.sdm.spa.util.*
XX> 
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> I would say joint files go under one project, with authors clearly
XX> listed in the file.

I think it's a non-starter. 

If I understand correctly, the whole point of the project-oriented
organization was to make clear what was produced by which project.
Nice at it may sound at first, it doesn't seem to work well for real
collaborations where developers from multiple projects contribute,
sometimes even to the same workflow or the same actor etc.

What does the project-oriented structure reflect if not "ownership"? 

(a) If it does, then we may need to live with 2^n directories for n
projects. Not very practical. 

(b) If it doesn't, why not organize the directories by a more functional
criterion and pull out "ownership" by selecting on the "author" (or
"project") field of files?


XX> If we put joint files in a common directory like util/, then that's also
XX> confusing.  Because you could have a scenario where SPA creates a file,
XX> but GEON subsequently helps to modify it significantly.  This would now
XX> qualify as a joint file, but should we move it from org.sdm.spa to util?

I think you just delivered another argument for a functional
organization instead of a project oriented one.

Bertram

XX> 
XX> What do you think?
XX> 
XX> Xiaowen