> > 1. Is the planned order of implementing things like you have specified > in the numbering of the things to do (ie. first AAA, then Brokering, > then Optimization/GA stuff)? It seems like this makes sense, since the > AAA stuff is kind of what we already have in the idl, combined with > the internal authentication system you've been talking about. Then we > need to figure out what is going on with remote applications, etc. I > was just curious about the development plan. I planned my todo list in this order: 1. Remove all fixed stuff in GMS, which I've finished coding and is being debugged atm. (It had some consequences so it took a lot more work as I had fought) 2. Link to Overflow libraries (compiling GMS sources as C++, writing code that communicates with Overflow, etc.) 3. Debug \ extend the threading. 4. Implement the AAA according to the Piper DL-BL idl. 5. Write BL->BL communication code (plugins that are KQML compliant) After these points there's more work todo, but I am not sure about the order here: 6. Batch code 7. GAP engine > > 2. How does KQML, which you mentioned really wanting to use before, > fit into this framework? Is this planned to be used for communication > within the BL, remote communications, etc. etc. Just curious how this > fits in. See 5. of the TODO. > > 3. In the optimization section you wrote: "Note this system requieres > a network of SINGLE type nodes, the +/- 120 diff. node types of the PL > can never be 'compared' to each other." Can you explain more about > what you are talking about here? I don't really understand your idea > for a 'single' type node, and how this will fit in with the framework > on how things working in the PL right now. With the term 'single type object' I mean a system that is based on ONE object type, opposing a system that consists of many different type. GMS is based on the object (which OOP people would call a 'structure') messaging_object, and no other type is used for node representation. Why I do this? The BL will need to optimize resources like load \ space \ time \ bandwidth etc. and NOT the actual data processing. In other words: the BL wont take heed of what is going on, but how things run. The 'value' of a node depends on the resources it consumes, not on what it does to the data it contains. To compare these values they must represent the same node type. Nodes with high values (weights) require less resources and will be scheduled on systems that have high load, and nodes with low weights are redirected to systems with lot of idle resources. Each [time frame] the weights for all BL nodes are recalculated and rescheduled accordingly. So the BL will handle this situation: (1) Network definition (UI\DL) -> (2) BL nodes resources consumption || (3) net system resources <- (4) gross system resources ('->' = 'results into' or 'simplicity', and '||' is the contradicting border between two interests) Recalculation of the weight will be based upon (2) and (3), but will be influenced by (1) and (4) indirectly of course. Am I being clear? I probably forgot some critical element that's obvious to me, so feel free to ask more details if you're interested. I wont answer till wednesday, I'm gone now to catch my plane... and miss the Euro2000 match TheNetherlands-Jugoslavia :(( bye, jarl