replicator.org ... continuous garbage collection

Both, the association system, I called tlists (from type-lists) and the focusmanager are implemented and working.

In fact, the focusmanager is working much better than in my 3D prototype I’ve made in 2000. The mouse feedback is very acceptible for touch interaction. You touch an object, and the camera will move itsself into the best position to focus it, with the mouse cursor not leaving the appropriate position in the 3D plane of the focused object.

Ok, this time I won’t stop at that point. The paramatrix 3 framework (yes, it’s the third implementation, since 1999) is now prepared to support everything required to build a really fine 3D user interface client/server framework.

The next step on my list is to support zombie objects (thanks to Steve for the naming). These are objects about to be deleted, but not yet able removed from the model or from the view, because asynchronous events may refer to them. The first idea was to use something like reference counting or a more generic garbage collector. But finally, I came across a simpler idea, and I hope this one is capable to cover the basic requirements:

• Application clients must be able to detect and ignore events from objects recently deleted and therefore require an commitment notification from the model server for each object completely deleted: When an application client sends a delete request to the model server, it cannot be sure to have received all events associated for the deleted object, so the client must store them in a zombie list and wait for the model server to commit the deletion until it can free the object’s id and expect events to refer only to living objects. Since the object’s id allocation mechanism may reallocate the same id immediately for a new object, this requirement must be met.

• The model server faces the same problem concerning its distributed view clients. View clients may send events to objects already deleted on the model side, so even the model server must protect itsself from accidentally reusing ids and delivering outdated events. Since all views are getting all objects, this should be solvable by maintaining a list of zombie objects for each view client.

I hope, that I will be able to integrate these mechanisms in the next few days to prepare the event system, which is required to deliver keyboard events to the currently focused application. Hmm, I am getting nearer to the point when I will be able to start working in my own 3D terminal server.

Keep focused.