> first question: can the independent models just drop and fd in /srv > and talk to each other that way, as 9p servers? Present resources as > files which are read and written to (not real files, of course; that's > just how they look). Then you can enumerate the capabilities of a > model by ls and friends.
I am not sure I know what you mean by "drop", but if you mean drop into /srv, then yes that would work. It looks like I was thinking about it completely wrong. Sorry. > It's a question of coupling. Are they so tightly coupled they need to > share memory space or can they be more loosely coupled? This is a question of efficiency. In the past, and eventually, I would like to have both, but for now having it work through /srv et al. > If they really need to share an address space, then we can talk about > how to do dynamic module loading/unloading; it's pretty easy and I > have sample code somewhere. The address space only comes into play with model/resource discovery (which can be hard coded in a configuration file), and possibly with data scoping rules (which gets complicated has heck because that is needed for data mining during a meta-model restructuring). Let me focus on the /srv implementation and bother you later with loading/unloading for tightly coupling to increase efficiency on a given core. > Is this python or C? C, but once it is working getting Python and maybe (cringe) FORTRAN would be great -- but that is for a later expansion. EBo -- -- You received this message because you are subscribed to the Google Groups "Plan 9 Google Summer of Code" group. To post to this group, send email to plan9-g...@googlegroups.com. To unsubscribe from this group, send email to plan9-gsoc+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/plan9-gsoc?hl=en.
