constancy....sweet constancy

since i was doing such a horrible job of updating my innerspace entries (due in part to the horrible job i've been doing of finishing the aforementioned software), i've integrated those entries into my main blog at bubblehouse. hopefully this will catch my attention enough to make me finish what i started.

probably not, though ;-)

ViewCVS issues

I realized the link to the left for my cvs repository has been broken for some time....i changed the link on the bubblehouse front page, but not here. It's fixed now.

Anyways, I expect to post a real status update sometime soon.

some info

I got a message from someone who was interested in pooking around InnerSpace today, and spent enough time providing some starter instructions that I figured I'd post them here.

some updates...

So, as it's been awhile since I've updated, I have lots of new developments. I've been fortunate to find some time to tinker with IS, and there's lots of cool stuff coming along.

I've also removed the CVS directory from sourceforge, as I wasn't using it, since I prefer to use my own repository for now. Once I get to a releasable 1.0 candidate, I may mirror my repository to sf, but for now you can access the bubblehouse web-repository using the links to the left. I will eventually open up pserver access through my firewall, but until i get some more interest in this I'm not going to bother.

Oh, and I've also started adding some unit-testing, using python's unittest modules. I'm quickly becoming a believer in unit-testing, since I found a slew of bugs in the parser and registry (the only two tests i've made yet). I will need to make a unit-test for the entity.py behemoth, but i'm probably going to hold off until I implement ACLs for permissions instead of the "rwx" business, which will probably happen in the near future.

You can read the rest of this entry for more details, but the improvements/changes include:

• Licensing - now under the GPL
  
• Parser - all new parser engine
  
• Verbs - enhanced developer functionality
  
• Plugins - support for new "core" packages
  
• Observations - dynamic observations engine for different clients
  
• Security - ideas on a secure environment for verb authors
  
• Build System - building and installation of client and server packages
  

Nice New Things

Ch-ch-ch-ch-changes...

First of all, welcome to the latest-greatest version of the InnerSpace website. Since I slacked off so much on updating recently, I decided to start using Moveable Type to make a weblog for this site. Considering it greatly simplifies the process for me, I hope to be able to post more frequently.

I have a bit more time to talk about some of the changes going on in the InnerSpace codebase. One of the biggest things has to do with some problems with Python 2.0.

During the creation of Python 2.0, it was discovered that new class features break the RExec and Bastion modules. They no longer provide true security from untrusted code. This is obviously a big deal, since this is something projects like InnerSpace (including the Grail web browser, and, to some extent, the Zope project) rely on heavily. Some additional explanation of the situation can be found here and here.

However, PythonLabs has pretty much said they have neither the resources to fix what's wrong with RExec/Bastion, nor provide a new solution. So, this kinda sucks.

Whoa! That's a Spicy Meatball!!

So, it's been a pretty long time since i've updated anything on this page. This is, however, no indication of work being done on InnerSpace; as a matter of fact, things are better than ever!
I've been restructuring some of the less stable components of the framework, namely, the network layer. I've opted to use the Twisted framework to provide a networking layer. This allows me to focus on the stuff that's important for a framework like this, while having the assurance of a rock-solid networking foundation.
As of yet, I haven't updated the CVS repository with the new stuff -- this is definitely on the way. I'm under some time restraints, as I finally have a job, and that's taking up a lot of my time. However, here are some things you can look forward to.

• A new and nicer client, which provides some facilities for nicer text, embedded images, and a generally nicer (and more functional) experience.
  
• A fully operational verb/object and property editor.
  
• A much more efficient networking layer (thanks to Twisted).
  
• and much more...
  

Posterity Tarball

With this, the role of InnerSpace as my project for CSC436 has ended. Although I really didn't get as far as I would have liked, IS is in a reasonably functional state. There is currently no documentation or even code comments, but that will be for another version. I'm still going to grant this release the title of innerspace-0.5...

Milestones

A couple weeks ago, we came up with a milestone chart for the rest of the project. Now they're finally posted!

• Milestone 1 06/24/01
  
  
  
  • [Done] Add variables to executing verb's namespace
    
  • [Done] Execute verb code in child process
    
  • [Done] Filter out remote stubs
    
  
  
• Milestone 2 07/08/01
  
  
  
  • [Done] Allow for out of band commands in the client
    
  • Implement GUI for object editing
    
  • [Done] Implement Observation mechanism in objects
    
  
  
• Milestone 3 07/15/01
  
  
  
  • Add convenience methods to environment
    
    
    
    • create/destroy objects
      
    • set/get property info
      
    • get user list
      
    • get active task list/kill tasks/view task info
      
    
    
  
  
• Milestone 4 08/01/01
  
  
  
  • Implement basic navigation
    
  • Implement communication between players
    
  • Rudimentary puzzles/areas
    
  
  

CSC436 at SUNY Oswego

I'm going to be using InnerSpace as my project for Doug Lea's Network Systems class at SUNY Oswego. This is good for a couple of reasons. First of all, it'll motivate me to find more time to finish this thing that's been on my back for so very long. Second, I'll be working with Greg Roberts, who will provide a valuable perspective, since he's fairly unfamiliar with Python and especially InnerSpace. He'll be helping me write verbs for the game, which will serve to teach him Python, show me were things are difficult or confusing, and also locate the numerous bugs that are probably just waiting to pop out. Finally, I'll have access to DL's brain. ("eeexcellent...")

Introduction

Hrm, well, where to begin? InnerSpace has been in the design process for four years now, and has been written and rewritten many, many times. Each time I always thought, "Oh, I've got everything figured out, so I should be finished Real Soon Now." Ha!

So What Is It?

The buzzword-compliant description would be: InnerSpace is a text-based virtual reality framework that allows multiple Internet users to connect to, manipulate and aid in the creation of a limitless universe.

In other words, it's a MUD, but it's the best damn MUD out there!

History

Initially, this project started as a port of LambdaMOO to Java. Of course, I didn't even get halfway through the first design without realizing a million things that were either A.) annoying design choices in LambdaMOO, or B.) practically impossible to implement in Java. I got pretty far, too, before I realized this (in fact, I still have the original version of InnerSpace written in Java using mucho RMI ). I realized that there were a number of things that I wanted to implement that other MUD/MOO/M* packages just didn't. BTW, I'm going to use the phrase MUD from here on, even though it's an oversimplification.

Things MUDs Should Have

• Authoring Support/Permissions Model - I wanted to be able to safely give any user programmer's rights, without having to worry about the havoc they could bring on the system.
  
• An Elegant Internal Programming Language - Initially, I was going to just embed a Python interpreter into my Java code, but I realized that Python's cool factor was just too great. So now the whole server is written in Python.
  
• Better Object Referencing - Most MUDs suffer from issues with naming objects. There's basically two established methods; you either assign each object an arbitrary unique ID (LambdaMOO's method), or ensure that no two objects share the same name. These methods had various shortcomings. If each object had a unique ID number, you could allow the name property on various objects to be the same. However, the drawback was that if your player character was not physically in the same room as the object you wanted to refer to, you were forced to refer to it by it's ID, like #175847. Conversely, if each object has a unique internal name, you'd be able to refer to something like candle(4). However, for things to look less intrusive, you had to set a special property that would change the name users saw when they looked at an object. You then assigned an aliases property that would provide a number of other ways to refer to the object.
  
  My solution is nicer, I think. The inner.space.registry keeps track of all objects by name and ID. So for the most part, you just refer to objects by their name. But if there's more than one item with that name, an AmbiguousError is raised by the parser, which asks "When you say, 'candle', do you mean candle (#456), candle (#726), or candle (#5)?"
  
• A Graphical Object Editor - So I may have come to appreciate UNIX, but I still love my Macintosh. By the same token, I want to be able to see at a glance all the major attributes of an object and be able to edit them easily.
  

So Much Code, So Little Time

• All game objects (users, rooms, doors, etc.) are represented by one class. Any object can potentially be a container for other objects, though by default they are not. Objects have a parent, which gets consulted if a selected property or verb isn't found on the child.
• Every command entered by the user forks a new process to run the code in. That way a malicious (or stupid) user can't lock up the rest of the system, only it's verb call.
• The Pyro (PYthon Remote Objects) package is used to allow child processes access to the world's objects. It's been rather elegantly hacked (I think) to allow a sort of verification by remote code, so the (yet unwritten) object editor can be a little easier to write, while still being fairly secure.
• The InnerSpace client is still written in Java, which allows for easy distribution by applet or other platform-independent method.