> 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