(FC-Devel) General next steps

[Jeff Wolfe <jwolfe@felgroup.creol.ucf.edu>]

Sorry I haven't been deep in the messages this week.  Things
have been real busy at work.  Anyway, I believe we have a
few issues left to work out.  I'll place all of them in a
list.  Please feel free to respond in pieces and not to the
whole message.

1) Organization - Based on the comments in this group, the
number of people now registered as volunteers and the
portions people are interested in, I will be creating teams
during the next week and posting that information to the
list.  I will ask members of each team to select a team
leader.  I do not intend to lead any particular team,
because of my responsibility to the project as a whole.

2) Selection of teams/components - We need to define exactly
what the components will be.  At this time, the exact
distinction of wether a component is separate process ot not
is not really that important.  I just want to make sure that
each component has a team.

3) Requirements - We are destined to failure if we don't
have some scope-limitting requirements for each component. 
There have been suggestions of some pretty lofty features
that are very worthwhile.  However, I think we would best be
served by a strong fundamental architecture and core feature
set.  It should be the responsibility of each team to
produce a requirements/concept document for their
component.  It is not my intention to produce lots of paper,
just to get something down that we can focus on.

4) Interprocess communication - At this time, we have not
selected a technology for communication.  There are 3 major
choices available to us.  CORBA, DCOM, and sockets. 
Personally, I believe CORBA and DCOM are equivalent for our
purposes. (Don't flame me, or start some longwinded debate
on this topic.)  The problem is that we will segragate about
50% of our users by going one way or the other.  My
architecture diagram proposed an alternative approach
(secondary interface servers).  In that approach, the main
interface would be through sockets.  Commands would be
modeled after the command pattern and extended to support
serialization in a format defined by us.  Next, secondary
interface servers could be developed for CORBA, DCOM, Java
RMI, Java serilazation or whatever else.  This is simply my
suggestion, and would allow us to truly connect anything. 
If you prefer a particular intrface, you could develop a
secondary interface server to adapt your xyz technology to
our server's or any other secondary interface server's
interface.  Let's work this detail out very soon.  Selection
of a middleware technology could have significant impact on
our design.

We also need to decide if communication will be a star
topology or a mesh topology.  Said another way, will we have
each piece tied to each other, or only the server?

Side note:  I am currently designing a commercial system
with DCOM and have also designed with sockets.  I believe
that using ACE is equivalent to using sockets (from a
communcation point of view).

5) Model storage - There are two major sub-items here.  A)
Storage of the user created model (diagrams, classes, code?)
and B) Exporting the diagrams to external formats.  This may
be a job for the repository team.  Anyway, this should be
addressed in the requirements doc for the repository.  As a
note, the specification of an internal format does not
preclude any export formats.  New ones should be able to be
added by creating add-ons.  I believe discussion of XMI,
XML, UXF, etc would go under section 5.

6) What to do with Argo and next steps - I believe it would
be good to look under the hood and see where we can strip
out code and plug in.  Since there is no persistance,
consider the following.  Let's get a simple repository
working with basic networking implemented.  In parallel,
we'll add persistance to Argo via the repository.  Then,
with minimal work, we will have a UML editor and distributed
repository.  Maybe this is harder than it sounds.  It seems
like a quick way to get one's whistle wet.

I believe our projects will not likely merge into one single
project.  It is likely that we will not elect the
no-restriction license and it would not be possible to GPL
code directly into non-GPL code.  It looks like we will take
Argo as a starting point and build pieces from there.

Boy, this is a lot of text.  Sorry it turned out so long. 
I'm just trying to keep up with the rest of you. :)

Regards,
Jeff