Re: [Gnome-devtools] Language Analysis Framework

[Thomas Mailund <mailund mail1 stofanet dk>]

>>>>> "D" == Dave Camp <campd oit edu> writes:

 D> Mark <jamess1 wwnet com> writes:
 >> Those are the main issues, overall I think I have a pretty good
 >> grasp of the framework. The data structures and interfaces I've
 >> designed are a bit sketchy though. It is hard to figure out in
 >> advance how the components will interact, what data is required,
 >> and the proper interface for the components.

 D> I have a few questions about the best way to integrate this with
 D> the rest of the gnome devtools.  The component-based design of our
 D> environment will create some problems the harmonia people did not
 D> have to deal with.

 D> First of all, the language analysis will need to get data from
 D> different components, most likely through corba.  As I understand
 D> it, a lot of communication must happen to keep the structure
 D> representation up-to-date with the editor.  We will need to figure
 D> out how this will be done.

I was kinda imagining that the structure here kept all the information
found in the source (lexical, AST, some symbolic info.) and that it
worked with other components in a model/controller/view architecture,
i.e. this structure has all the data and the other components show
different views of this data and/or manipulates this data.

 [editor]
     +--<source view>-----------+[ AST ]
     +--<source controller>-----+[     ]+---------+[UML viewer]
                                 [     ]
 [indenter]+-<source controller>+[     ]

The individual components does not have their own copies of the data,
they manipulate the data directly and get notified of other changes.

 D> The second problem is that many different components will need
 D> access to the information generated from the analysis of the
 D> documents.  Class browsers, editors, etc. will all need to access
 D> and modify the data stored in the structural representation.  I
 D> see two options: 1) having each client maintain their own
 D> representation, and 2) having a single server which stores the
 D> structural representation and provides access to clients.

The later is the Right Solution(tm) IMHO.

 D> The first solution will require that we keep every client in sync
 D> with each other, and could mean basically repeating the same work
 D> for each component a few different times.

 D> The second solution is also difficult.  Exporting complex data
 D> structures through corba is a huge pain in the ass, and isn't
 D> particularly efficient.  The only way this could really be done
 D> would be to create a shared memory area for the structural
 D> representation, and use corba for smaller things like
 D> notification.

Most of the time, the viewers are only interested in notifications.
They need to know the structure when they show it for the first time,
but after that they are just notified when something changes, and then
they update whatever it is they show.

Of course, if they do not show the entire structure at once, there
should be ways to get parts of it and such.

I'm not too happy about the shared memory idea.  It prevents views
from running on different machines.

 D> Any thoughts?

yup.

        /mailund