MV3D Development Blog

I keep making these tickets to do what I think will be fairly straight forward things, and then once I start getting into them, I realize that it’d be better to do a whole lot of refactoring and cleanup. The little ticket suddenly becomes a multi-week or multi-month project. I’m stuck on one of those now, actually.

I wanted to just go in and de-couple sub-servers from their names. Previously, you had a Server, and you could give it sub-servers that would handle things like accounts, assets, simulation, etc. There were a couple of problems with how that worked. First off, it ended up that in order to run the most simple MV3D server, you basically needed one of each. Secondly, there really wasn’t any way to use them as plugins. You couldn’t have an alternate implementation of an account server that you threw in. They all also heavily relied on the main server object. So, I thought I’d see about making them pluggable and less reliant on the main server. Sounds good, right?

As I got into it, I noticed that the implementation was pretty horrible and would need major changes (it was probably the oldest code in MV3D). One thing that I’ve been thinking about is reducing the reliance MV3D has on PB and allowing the possibility for it to speak other protocols. The main push behind this was the authentication scheme I mentioned in the last post. I was also seeing that the Client class had 90% of the same code as the Server class. The Client has notions of sub clients, which some of directly map to sub servers.

From all this came the Conductor. His job is to manage a set of services and keep them in sync. I still didn’t think this would be a huge thing to do. Just some search and replace and stuff. The problem came when I wanted to change the hard coded sub server names into something you could specify in a config file. See, things like the asset sub server always use the name “Asset Server.” I decided this was pretty silly and that you should be able to name them in case you wanted to have a couple types of asset services around. The main problem there is that when one service wants to talk to another, it used to be able to just look for a specific named service attached to the main server. Can’t do that any more. It all has to be in the config file. Not so bad. Then I started looking at how things get remote connections. The main server class handled that through a connection manager object. The purpose of the connection manager was to make sure that you didn’t open up a new connection every time you needed something. In many cases, you’ll already have an open PB connection and can just make use of it.

Only it was again some of the original MV3D code and is fairly badly implemented. I was also thinking about how multiple open network ports (speaking different protocols) would work. It wouldn’t, basically. So the connection manager had to go (it was dumb anyway). Everywhere in MV3D that tries to open a new PB connection is just looking to talk to a specific sub server (now called service). It would indeed be cool to be able to have some sort of service locater that basically pointed to a specific service on a specific box and included information about the protocol to use.

So, now, I’ve rearranged everything so that what was the connection manager split into two: a client and a server. The server side is now just another service you can add into the conductor. The client side follows an interface that can be used for other protocols as well as PB (connection manager only understood PB). So, now, you just tell the conductor to get you a service and give it the location like conductor.getService(”pb://mv3d.com/sim”). It’s pretty cool, and maybe 1000-2000 less lines. You can even specify local services as “self/auth”.

Unfortunately, now, I have to go through everywhere that used to open a new connection and change how it works. Nothing like making extra work for myself! However, I’m happy with this change, and I think it does a lot to make the inner workings of MV3D more flexible and easy to work with. That’s one of the big things I want to work on before releasing the code.