IDE, IDL feedback needed.

[Samuel Ziegler <ziegler bayarea net>]

To get as much feedback as possible, I am posting this to both the
GUIDE and Gnome mailing lists.  Most of it is an analysis of what I
feel the IDE should be, but what I need feedback on is really the IDL.
So if you don't feel like you need to hear my motivations, skip down
to the IDL. 



Ok... here it goes.  As I see it, you guys are trying to reinvent the
wheel. As the GUIDE web page states, the point of this project should
be to "merge existing" utilities into a single IDE.  This should be
the first step.  And it is no small step.  As I told Knud, whether or
not the editor displays the source folded or not should note be the
IDE's problem.  The beauty of an IDE based on CORBA is that the IDE
doesn't have to worry about the individual pieces, it just has to
worry about connecting them all together. 

If you want to write a fancy editor which folds text and does syntax
completion, more power to you.  However, this has been done to death.
What has not been done, and should be the goal of this project, is to
join all these editors, debuggers, version control systems, etc.  So
they all can work together.  People have editors they like, people
have their favorite debugger.  Our goal should be to allow them to
work seamlessly with each other. 

To accomplish this, we have to come up with a coherent set of IDL
interfaces which encompass most (it is impossible to do all) of the
features of each part of the system.  Then grab every
editor/debugger/class browser/whatever we can get our hands on and
implement the approprate interfaces for them.  That way programming
team X can all work on a project together and share project files /
source control / etc, yet each member of the team will be able to use
the tools they are most comfortable with. 

So my point is this:  If you want to write a cool text editor or
debugger or whatever, that's great.  But that wont help integrate them
together. 

So with this in mind, here is my second pass at the IDL. (with
documentation!)  Now this is still far from completion, but it is a
start. 

First here is a brief run down about CORBA and how it is used:
The point of CORBA is to create a system which will allow programs
writen in pretty much any language you can think of to communicate
with each other in a way which hides the method of communication from
the participants.  This is achieved by first creating an IDL (or
interface description language).  The IDL is writen in a language of
it's own, then put through an IDL compiler with generates the stubs
for whatever language you want.  Now, the CORBA scheme is a two tier
system where you have clients talking to servers.  A program can be
both a client and a server throughout it's lifetime, but in a single
transation it is either the client or the server.  The server is the
program which defines the interface which the client is making a
method call on.  Now when a client makes a call on a server, it has no
idea where this server is or what this server is.  All it knows is
that it was given a referance by the ORB which implements a given
interface.  For all it knows, it could be talking to itself (which, in
our system, may be possible.  For example, an editor which already has
a built in debugger.  More on this later.)   

Since when you are making a CORBA call you have no idea where the
actual server you are talking with is, a major design goal when
creating interfaces is to limit the number of times you have to make
calls along the wire.  Unfortunatly, in an IDE the parts of the IDE
are going to have to communicate fairly frequently (especially when
debugging) we are going to have to stretch this rule a bit. 


Now to the good stuff.

My concept for the IDL began with the thought that a file is the
atomic unit of an IDE. Editors / debuggers / source control /
etc... all deal with things in terms of files. Also, the only other
piece of info needed to be passed around the IDE, in terms of files,
is a line number.  Ie, set a break point at line X... the current line
of execution is  Y...  Everything else is either dealt with within a
given piece of the IDE (ie editing a line of of the file) or by the
operating system (ie a file is read only).  Now this may be an
incorrect assumption, but it is the one I've been using so far.  

The basic concept is to have the IDE act as an intermediary between
all of the other parts of the system.  That way, whenever a piece
(say, the debugger) wants to talk to another piece (say, the editor)
it requests the approprate implementation from the IDE program.
Example: You want to debug a program, so you are in your editor and do
a set breakpoint.  The editor goes to the IDE and says "Give me the
debugger for this file / project / whatever."  The IDE then returns
you the appropreate debugger referance.  The editor then makes a set
breakpoint call into the debugger.  Then the editor does a run call on
the debugger.  When the debugger hits that breakpoint or another
breakpoint it goes to the IDE and says "Give me the editor for this
file." The IDE returns the referance to the Editor implemention then
the debugger makes a call to the interface to open the given file to
the given line... etc... etc... etc...

The bad news is that having a more passive IDE means that more of the
code is pushed off onto the individual components, increasing the time
and effort needed to implement the various interfaces.


Aaak.  Too much typing for me... I'm going to sleep.  Well that's much
more than my 2 cents.


-- BEGIN IDL --
module guide {

  // Basic unit in the system.  More info will probablly have to be
  // added to it, like version number, etc, but this is good for now.
  struct File {
    string filename;
    string path;
    long lineNumber;
  };

  // Execption thrown when a File passed the the given method did not
  // match a file on the system.
  exception FileNotFound {
    string reason;
  };

  // Thrown if the lineNumber param of the File is out of range.
  exception InvalidLineNumber {
    string reason;
  };

  interface Editor {
    // Sets the current working directory
    void setCurrentDirectory(in string path);

    // Opens the given file
    void openFile(in File file) raises (FileNotFound);

    // Save the current file
    void saveFile();

    // Places the cursor on the given line, returning the old line number
    long gotoLine(in long lineNumber) raises (InvalidLineNumber);
 
    // Marks the given line as a breakpoint.  This should probably be 
    // changed to some method where the IDE keeps track of all of the
    // characteristics of a given file (breakpoints, keywords, etc)
    // and communicates them to the Editor for display purposes.
    boolean toggleBreakpoint(in long lineNumber) raises (InvalidLineNumber);
  };

  // The specified project was not found in the system.
  exception ProjectNotFound {
    string reason;
  };

  exception ProjectAlreadyExists {
    string reason;
  };

  exception FileAlreadyExists {
    string reason;
  };

  exception MergeConflict {
    string reason;
  };

  // My concept of a Project is a subset of the version control system.
  // Typically you would get an instance of a VersionCOntrolSystem
  // from the IDE then ask this object for the Project of the given
  // name.  You then use this to communicate with the system itself.

  typedef sequence<File> FileList;

  interface Project {
    // Checks out the given files
    void checkOut(in FileList files) raises (FileNotFound);

    // Add files to the project
    void addFiles(in FileList files) raises (FileAlreadyExists);

    // Remove files from the project
    void removeFiles(in FileList files) raises (FileNotFound);

    // Check in the given files
    void checkIn(in FileList files) raises (MergeConflict);

    // Gets the latest version of the files
    void getLatestVersion(in FileList files) raises (FileNotFound);
  };

  interface VersionControlSystem {
    // Get the interface for the given project
    Project getProject(in string projectName) raises (ProjectNotFound);

    // Create a new project
    Project createProject(in string projectName) raises (ProjectAlreadyExists);

    // Delete a project
    void deleteProject(in string projectName) raises (ProjectNotFound);
  };

  struct Error {
    string errorMessage;
    File file;
  };

  typedef sequence<Error> ErrorList;

  interface Errors {
    boolean hasErrors();
    ErrorList getErrors();
    boolean hasWarnings();
    ErrorList getWarnings();
  };

  interface Linker : Errors {
    // Link all of the given files into the outputFile
    boolean linkFiles(in File outputFile, in FileList files) raises (FileNotFound);
  };

  interface Compiler : Errors {
    // Compile all of the given files
    boolean compileFiles(in FileList files) raises (FileNotFound);

    // Get the list of files created by the compile
    FileList getResultFiles();
  };

  interface Debugger {
    File stepOver();
    File stepInto();
    File stepOut();
    File restart();
  };

  interface IDE : Errors {
    boolean compileProject(in Project project);
    void generateMakefile(in File makefile, in Project project);
    Debugger getDebugger(in File file);
    Editor getEditor(in File file);
    Compiler getCompiler(in File file);
    Linker getLinker(in File file);
    VersionControlSystem getVCS(in File file);
  };
};
-- END IDL --
-- 
Sam Ziegler / ziegler@mediaguaranty.com / sam@ziegler.org
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)