Stage Meeting Sumary (7th April 2002)

The meeting was focused on discussing some medium to long-term plans for stage, based on people's experience over the past six months or so.

James put forward a number of proposed changes, summarised below:

  1. seperate the out-of-game and in-game systems into seperate programs
  2. move towards a CGI-style model for RIMs, with each rim being a sub-process linked against a common stub DLL providing a well defined interface (equivalent to provided by shepherd at the moment).
  3. Make these components communicate via Atlas over sockets

The basic goal of these changes is to make the code more maintainable and testable, and to decrease the size of code people have to work with.

Most people seemed basically agreed that these changes would be a worthwhile improvement. Various people raised issue of performance impact, though it was pointed out that once a working system is built, various options exist to improve performance, up to and including moving rims back into threads.

Nikal and others pointed out that getting 0.1 out should be a prioirty before any dramatic changes are made; James mentioned this was the point raised by Damien in earlier discussions.

Demitar queried how common data structures would be shared efficently in a distributed model, and malcom noted that simply changing the design would probably not reduce either the amount of effort or the amount of bugs for solvig a given task.

Grimicus briefly mentioned replacing Galileo with log4cpp, and was tasked to go and investigate if it has any potential.

James noted that the current IPC primtives (mutexes / threads / etc) are especially poor, and it was noted by Demitar that if most communication is being done via Atlas, many of these issues go away immediately.

There was some discussion of the current RIM interface (and how much rims use internal data), and how a new interface would be specified. James suggested that the new interface would resemble the current Entity and Container classes, plus Pan, Proteus and a few other things.

Demitar proposed an order in which these changes could be attempted:

 1. make oog run independently

 2. hook ig up

 3. define a good rim interfacing protocol

 4. split out rims

5. make lots and lots of rims

There was some discussion of the ordering of items 2-4, but most people seemed entirely in agreement about the overall plan of attack.

This was followed by some discussion of how Orion interacts with this model. Several people suggested Orion should simply be a rim, but this was felt to be too restrictive by Rakshasa and James. Grimicus suggested making Orion another library which rim processes could potentially link to if they needed too, and several other people agreed. Rakshasa raised several issue about allowing rims to supply custom force and collisions-response methods to Orion in this model, and especially the importance of avoiding a round-trip to the rim for such issues.

One possible solution discussed was allowing very small custom plug-ins to orion, but it was pointed out that allowing such modifications of Orion is probably a long-term need anyway. Neverthless, most people seemed to agree this approach would be viable in the future.

Following the design points, there was some discussion of recent development and the path to 0.1. Damien's current bug-fixing work, and James' fatigure with the code were discussed. Bear asked about reverting to a previous stable version of Pan, but James' replied that there has actually never been one. The current work on re-writing Pan was discussed, as well as short-term solutions for stabilizing the existing code sufficently to release 0.1

There was some debate over the necessary features for a 0.1 release; notably Bear felt that releasing with persisence disabled was acceptable, while James disagreed. There was a general feeling that getting a stable release out should be the number one prioirty, and ways people could assist in that were discussed.

Finally, a problem with the test client ('process') was discussed. Grimicus asked whether this was related to the skstream2 transition he comitted, and also noted that he needed to remove the old socket code from util/. Demitar agreed to investigate the issue (Damien since located the probem, in process's network code).