Re: [Gnome-devtools] Language Analysis Framework

[Mark <jamess1 wwnet com>]

Thomas Mailund wrote:
> 
> >>>>> "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.

That is the beauty of the framework, that the individual components that
use it should not have to do that much work. A very basic editor would
only need to insert text into the document when text is inserted into
the editor, and delete text from the document when text is deleted from
the editor.

> 
>  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.

I like 2) as well.

> 
>  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.

There should be no need for storing the data in shared memory. Although
each view/controller will duplicate various ammounts of information. The
editor probably the most so, since it has to duplicate the entire text
of the document, and also some of the syntactic information for
highlighting/cross-referencing. Other views such as the class browser
will duplicate very little since it is only concerned with class parts
of the program.

I haven't thought of all the possible uses of the framework, so there
might be a case when you want the entire structure all the time. Perhaps
we could define efficient traversals of the structure that would be
similar to notifications but would traverse entire parts of the
structure. 

As far as the implentation, is COBRA the best solution? I'm just
wondering as I don't know a lot about it. I was orignally thinking of a
C interface accesed through a dynamic library, but I can see how this
solution would break down, when your talking about accessing information
from possibly a different computer. I'm going to have to read up some
more on COBRA.

Mark