Extending VRSpace


Extending space

OK, we're mad scientists in search for the final question of universe, life and everything, and we need some heavy-duty distributed space-time calculations, i.e.

Working in Minkowski spacetime, take some 3-spatial energy and compress it by the factor c-squared. Now what can be done with it? If we leave it there in 3-space, in x,y,z, it becomes what we call "mass". If we move it and place it over on the fourth Minkowski axis, ict, it becomes what we call "time".
;)

In VRSpace, a point in space is represented by Transform class; it's space's address space, unique address of anything within the space.
And it has x,y,z and other properties, but nothing like 'ict' Minkowski axis.
So we need to extend this Transform, in such a manner that all other classes which use Transform class use our new class... tricky;)
First we need new class in a new package, say org.vrspace.minkowski:

public class Transform extends org.vrspace.server.Transform {
  // your space representation here, i.e.
  public double ict = 0;
  // and of course, we will add new methods here which do actual space-time calculations
}

And then, we need to trick VRSpaceLoader to use new Transform class instead of the old one. Here's how VRSpaceLoader.init() does it:
    packages.add( "org.vrspace.server" );
    packages.add( "org.vrspace.server.object" );

We need to add org.vrspace.minkowski before org.vrspace.server in this ClassLoader... so:

1) Create new VRSpaceLoader and call addPackage() before init(), you'll have to subclass the loader for such a thing, as init gets called from constructor
or
2) Create new VRSpaceLoader and call removePackage() to remove org.vrspace.server and org.vrspace.server.object and add them again after org.vrspace.minkowski
or
3) Use vrspace.loader.packages property:
java -Dvrspace.loader.packages=org.vrspace.minkowski;org.vrspace.this;org.vrspace.that -jar whatever.jar

How can it work?
Polymorphism... new Transform is the old Transform... and voila, we just turned our VRSpace to VRSpaceTime;)

Now maybe you don't need really Minkowski space-time but you may need some VRML specifics, i.e. scale, axisOfOrientation and other VRML Transform properties; general suggestion is don't use them - you can't grow and shrink space elements just like that! But if you really have to change entire space into something else, this is how.
(And honestly, I've never tried it...:) If you ever do need such space stuff, let me know - jalmasi)

Commands

Clients can issue Commands:
- each Command is a brand new class instance
- client Thread blocks untill command execution is complete (Client still receives events but can't send)
- Commands may or may not send notification of completition back to the client; Dispatcher notifies Client in any case of execution failure
- Command has acces to Client which created it, and via Client's methods and properties, to all the space
And, each Client subclass has it's own Command set, in it's own package. Default command set is in org.vrspace.server.command package, commands in org.vrspace.server.command.Administrator can be executed only by Clients of Administrator class, etc.
Dispatcher looks in class-specific package first, then in default package.
And that's about all, this can even be used for simple scripting.


Plugins

In general, VRSpace plugins are wrappers around some other java programs. We need them if we want to add programs in the space.
Plugins extend VRObject or some of its subclasses; sometimes can be convenient to extend Client or even User, as Alice does.
A plugin can be a Daemon; Dispatcher loads all permanent Transforms at startup and starts those of them which are Daemons.
So Dispatcher plays much the same role like init process in unix, but each inittab entry is stored in the same space/database with other objects.
Thus, first decission in plugin design process is whether it will be Damon or not; it should be Damon if it can make some actions before first visitor arrives.
Note that we can turn on/off Daemon autostart any time by just turning on/off permanent flag of it's parent Transform. This may result in first visitor (addObserver call) before Daemon is initialized (startup() call) and has to be taken into account: VRSpace does not guarantee initializetion before first observer.

Second important decission is whether we'll extend Client or some other VRObject type. Well, it's rather application-specific:
If I want a robot which can do anything a user can do, I'll extend User class.
If I want a mail server which will announce new mails, I'll extend OwnedDBObject class.
If I want a buletin board where people can leave me messages, I'll extend PublicDBObject class.
Etc.
Most important thing here: Client has Scene. It's a box containing surrounding space.
So if you need access to other space objects, using Client extensions is much easier.
(Also, Client has Session and Dispatcher and can issue Commands and blah...)