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

[Terence Critchlow]

Hi Bertram,

I am very confused about your comments and don't think I understand your 
concerns.  In no particular order, the items confusing me include:

- My understanding is that the current directory structure is organized 
around projects, not capabilities (ie org/* ). Part of Xiaowen's goal is to 
minimize changes to the current directory structure so she is keeping that 
organization. If I am understanding it correctly, your proposal would 
completely restructure the entire repository - which is something we have 
been trying to avoid.

- From the perspective of where certain shared file go - this seems to be a 
problem that the developers have already worked out, since we don't have 
the shared directory at this time. Given they don't seem to have a problem, 
why is this a concern from your perspective?

- From the perspective of keeping the SPA and Kepler repositories sync'ed, 
it is a lot easier if the copy is based on the directory structure instead 
of identifying each file individually, but it is doable either way.

- I don't see why you would not have the same code location concerns under 
a domain specific approach - either you need to figure out that the 
browserUI interface was first applied to a blah workflow and thus is 
located in the blah directory, or you great a blah blah directory and put 
the code shared by those domains in that directory,  or you put everything 
that may possibly be shared into a single directory creating a huge mess. 
Given the number of application domains is larger than the number of 
projects, I could see this actually being worse overall.

- You have a good point about the problem of identifying what actors 
currently exist and where they are. This could be resolved if each project 
kept up a web page that described the actors that are currently available 
in their directories (differentiating the ones that are still works in 
progress from the ones that are ready to go). A main Kepler page could then 
either combine these pages or search across them.

- I can see arguments in favor of both a top-level utils directory and a 
project based one. Could we have both, with the understanding that the top 
level directory is for very general shared utility code (such as an XSLT 
parser) and the project level one being for general code where it is 
unclear whether or not other projects would really be interested in it.

- I am surprised that you expect there to be a lot of joint development at 
the actor level. I would have expected the collaborative work to occur more 
on the workflow level, with creating an actor being the responsibility of a 
specific developer. It seems like actors are developed based on a need 
(real or perceived) for a given workflow, and may be generalized (when 
created or later on) for other workflows. Is it the ongoing refinement of 
the actor that you are expecting, or do you really see multiple developers 
across projects working on a single actor at the same time?

Terence

At 09:44 AM 4/7/2004 -0700, Bertram Ludaescher wrote:
> >>>>> "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