Posted by: Peter Quirk | September 4, 2008

Object-orientation and realXtend

My server platform has been down for nearly a week as the hardware was relocated to another building. Some confusion about network connections has led to some additional delays, so I haven’t got much to report on about my experiments with realXtend. The real work begins when the server is restored and all the network addresses change. In the previous I was using fixed IP addresses. From now on I’ll be using FQDNs. Apart from changing a lot a configuration files, I’ll have to change IP addresses of avatars in the users table of the authentication database.

Meanwhile, I’ve been thinking about a lot about a unique feature of the realXtend platform that distinguishes it from Opensim – the ability to associate a Python class and method with an object. It’s a bit like the “code behind” feature of .aspx pages in Microsoft IIS. The realXtend documentation (section 3) provides a good example of how to associate an X10 class with a lamp. Touching the lamp object toggles the state of an associated X10 device. The limitation of the implementation is that you have to know the names of the methods. In the realXtend discussion group I raised the idea of providing a mechanism to enumerate certain methods and properties of the class (let’s call them menu methods) and present them in the pie menu of the object.

Since then it has become obvious to me that the same approach has some value when applied to avatars. Using the group(s) that an avatar belongs to, bind scripts of the same name to the avatar and expose the menu methods in the pie menu of the avatar. One compelling application of this approach would be making administrative methods available to certain avatars.

Looping back to the first idea, it would help if we had a group mechanism for objects – not the PowerPoint group per se, but a way of saying that an object is a member of a named type or project. Another way of thinking about this is to consider them to be equivalent to tags on blogs or photos. A script could be associated with the group name to provide a high-order function that operated on the entire set of objects in the group. This mechanism could replace the Builder’s Buddy scripts used to rez/de-rez buildings.

The next step is to consider the application of AOP (Aspect Oriented Programming) to the methods. Using AOP, one can supply additional methods that are called before or after a named method is executed. AOP techniques are often used to apply logging, de-serialization, or security methods to another method without changing its code. AOP depends on runtime environments like Python’s which support reflection. In an AOP-augmented realXtend, one could add a recording mechanism to the pie menu actions, implement a content inspection procedure on the “give” action, a background check on an “accept friendship” action, etc.

Imagine how much easier it would be to construct wikitecture-like systems if all objects had associated scripts, and if all actions could invoke server-side extension scripts! No more painstaking installation of Builder’s Buddy scripts – the create prim action would automatically insert them.

How would you apply such extensions? Is there an ugly problem they could solve for you?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: