roadmap

Indri Development Roadmap

Here's a rough plan of Indri development. Note there are no dates attached to this! If you want to work on an item let me (James) know and it shouldn't be an issue.

Milestone 1

Stand-alone script engine
- supports all basic JS flow control ops, i.e for / while / if / break / continue
- syntax (from JS, maybe modifed) to manipulating lists/arrays and maps/objects
- ultra basic string library (concatenation only?)
Test soft (user-space) threading of Puck, and see what (if any) locking issues arise.
Ensure Puck/Atlas layer works reliably, in both directions (partially done), and verify with stand-alone tests.

Milestone 2

Replace JS in indri with Puck
- make the entity and archetype maps hold puck objects
- make the type wrappers, such as Vector and EntityId use puck types
- make Account, Operation, Entity and Archetype work as puck natives
- Make the scheduler run tasklets. This will probably affect the Invoke object quite dramatically (Invoke simply becomes tasklet creation)
Purge all the threading stuff. Note threads may still be needed for specific IO related things, but initally let's stick with a single thread.
Move to Atlas-C++ 0.6, and use Puck primitives instead of Atlas ones. Should be tedious but simple work, barring uncovering weird bugs in the Puck Object code. Note Atlas::Objects can still be used for building operations to be sent, if desired.
Support agreed extensions to the type definition XML file.

0.1 release

Milestone 3

Extend the puck syntax to include 'states', similar to Unreal script. Need to decide which langauge objects can have a state (implemnt on object as a 'soft' attribute?) and decide the syntax. (something like case: statements?)
Extend puck syntax with some high-level programming things : probably an import keyword, and a package / module keyword, once there is a better idea what's needed.
Sort out entity persistence, probably by converting to Atlas::Binary or Binary2. Should be pretty simple, given reliable round-tripping to Atlas and BerkeleyDB
Sort out talking to Cyphesis to do the AI (new sub-class of Agent)
Get automatic generation of Set ops working. Note this should be allowed for when design Puck's member get/set methods.
Extend the Puck library, based on feedback. One obvious area is a good set of wrappers for Vector, with standard math operators defined for vectors. Don't want to go overboard here, physics should be done in C++, the Puck interface is more for high-level control.

0.2 release?

Milestone 4

Multi-serving. Make DB persistance a (very simple) server too, have a pool of instances which pass entities around via Atlas.
- need proxyEntity / remoteEntity holders for non-local entities
- script propogation / server control, need to be able to pass script or bytecode to other servers in the cluster.
- Entity ID allocation pools

Important tasks not mentioned above

Generally, these are areas which are semi-discrete - not areas which are unimportant!

Physics! - Ron has mentioned he would like to work on this once UClient calms down. ODE is almost certainly a bad bet. Emphasis should be on efficent, basic collisons (orientated bounding boxes would be fine). Could steal the cyphesis code initally.
View / portal logic - Damien has done some work laying the foundations for this, and it's worked once before, in STAGE, needs some love and attention however. Big scalability issues here, since appearance and sight ops dominate network load
Mercator integaration - a really crude integration has already been tried, whatever is done should be pretty lean, since all the hard work is on the client.