[Pipet Devel] Overview

Brad Chapman chapmanb at arches.uga.edu
Wed Mar 22 21:12:59 EST 2000


 > Jarl van Katwijk wrote:
>> 
>> I've been working this weekend a lot on GMS
>> to get some features done, but soon we'll have
>> to work a little more coordinated, so I
>> invite everybody to propose the things
>> they think need to be done for their 'own'
>> projects in order to bring us 3 together.
> 
> Brad and I want to propose a well-defined, GUI-to-core, XML-based, 
command
> stream.  But we do need to now how the GMS-Overflow relationship 
will turn
> out.

As I just mentioned, I think we can maintain the XML based streaming 
dialog while the GMS/Overflow merger is still in flux.
    What I would like to try and hash out is a plan for a CORBA 
interface with the GMS. I think for a rough outline it would need the 
following parts:

0. Initializing a connection between the "middle"/GUI and the 
processing engine.

1. A way to pass structured information (in the form of XML or DOM) to 
the processing engine, so that it can take this XML and use it to 
build it a pull network or neural net system.

2. A method for requesting a list of programs/libraries registered 
with the processing engine. I think the "middle" should keep XML 
descriptions of these separate from the processing engine, so this way 
we can keep the messaging objects light weight (ie. they don't need 
any knowledge of the description or other info about a program--just 
how to run it and get stuff back from it). This way the "middle" can 
also keep the XML files for programs organized into directories of 
similar programs, so they will be easy to find for the user. However, 
before giving a GUI access to a program representation, it will need 
to confirm with the middle that the 

3. Methods for querying the middle to determine the "status" of a 
process.

4. Methods for returning the generated info (ie. for viewing) to the 
GUI.

Others? This is just some stuff off the top of my head. I would like 
to keep it simple at first, if possible, but still keep all the 
functionality that GMS and Overflow currently have.

>> I'm trying to plan a very rough time-schedule
>> in which will be working.
> 
> Loci hasn't been working from a time schedule, but ahead and make 
one.

I would be happy to have one. I'm all about structure etc. The way my 
life works is that I work on things frantically all at once, and then 
get way behind in everything else and have to work frantically on 
them, but I can try to stick with a schedule :-) I think this would be 
very helpful for coordinating development etc.

>> I'll be doing some 'testing' using the
>> overflow library with gms, and will code
>> some planned gms features, which will
>> take around 2 weeks.  Maybe Overflow or
>> Loci are currently into a phase that will
>> take more time before any merge is possible.
> 
> I think Brad may be ready pretty soon to make a GMS-side library for
> communication with Loci's GUI.  Is that right, Brad?  It doesn't 
really
> matter
> for the GUI itself.
> Brad, would it be easier for you to make this 'library' in C++ 
(rather than
> C), since you know C++ better?  Jarl is using a C++ library 
(Overflow) anyway,
> correct?  Is this a viable option?

Shorely, I'm ready whenever Jarl is ready for me :-) Personally, I 
don't really care whether I use C or C++ and would like to avoid 
mixing languages as little as possible (too late for that, I know.) so 
I wouldn't have a big problem coding in C if that's what Jarl feels 
most comfortable with. As I said before, I don't have much experience 
with procedure oriented languages, but I would like very much to give 
it a shot.

>> -> How long before every project is ready for any merge attempt?
> 
> I'll let Brad answer that for me.

I think we're ready now <keeping my fingers tightly crossed> for any 
kind of merge. As we merge, I think we'll be able to see better what 
kind of functionality we need to add to what we have to support the 
current states of Loci and GMS.
    
    Jeff, you might want to have some discussions with the Overflow 
guys about the GUI. It seems like you both have come up with very 
similar ideas for how things should work, just with different names:

loci -> nodes
workspace -> network and subnetwork

They have some experimental stuff starting up--like iterators and 
threading, which I don't think the current GUI will support. I'm not 
sure how they feel about things and would like to handle this.
    For GMS, it seems like the move to this connect the dots type GUI 
will be a big change from the list oriented stuff it currently has, so 
Jarl's input will also be very important here. 
    We can definately do this, and I think we should start ASAP and 
just start squeezing things together and see how it goes. 
    Let me know where I can help the most and I'll start up there...

Brad







More information about the Pipet-Devel mailing list