[Pipet Devel] Overview

[jarl van katwijk]

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

This will be a good starting point.

> 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 needing one more weekend before the 'merge phase'.
I'm thinkg about around 2 months time for doing a merge-pilot, not
a day-to-day schedule. That might come later :)

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

C is more suitable for the 'inbetween' functionality gms will get in the
VSH
design. It has more 'hackish' functionality.
But i'm also quite happy about Overflow & GUI being OOP because it makes
sence to build those OOP.

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

OK, then I will communicate with Brad about the details.. any dessision
that will infuence design etc will be posted pubically ofcourse.

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

The GUI is list-orientated. This sucks. The engine is build on a
fully-connected network structure that supports Loci's approarch.
Like I said in one of my very first posts in the Loci mailinglist: I was
looking for a better GUI to replace mine.

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

K, maybe it's logical that you'll do this 'in-between' code that talks to

the gui and the core?


bye
jarl