Status Report for March 15 to THE END
The vmware problem caused by using the InetAddress.getLocalHost() to get the interface for all of one.world to use seems to post a more general question: What happens if you want varying components to operate across different interfaces? An example might be a space station data processing application which collects data from several computers on a local area network located on the space station and then dispatches the results via a satellite interface back to some undisclosed place deep in the deserts of New Mexico. It seems that applications such as these would require that each component be able to choose a particular network interface to send data, rather then defaulting to just one.
It would be nice if one.world had more debugging interfaces. Obviously the nature of how one.world applications are run is going to limit some methods of debugging. Breakpoints in such an asynchronous environment may be completely impractical for most debugging just because they require the application to basically stop and then suddenly resume. However, I think that in a generally asynchronous distributed application programming interface like one.world, other utilities may prove very useful. Since most of my time has been trying to debug code, I figure I should try to think of some debugging utilities that would have helped me the most. Here are my thoughts:
Imagine if during testing you could register a dummy component and use it to actually communicate with other components (where you send events during runtime by typing them in, and view events received). This would allow you to develop a certain component (say, component A) that communicates with components B without actually having to write component B. You can basically complete A, and then create an instance of A and a dummy instance of B. Using B you can then connect to A, send messages and review responses received from A as well as test certain conditions with ease. Perhaps also you could even impersonate an already existing component by sending messages on its behalf (impersonation might be a very bad idea). I believe that these two things would allow you to develop and test components in smaller increments and run specific scenarios and special cases of your code.
One extremely useful debugging utility would be something that allowed you to create a network of virtual computers and then create instances of components on these computers. It seems to me that a good amount of the difficulty of distributed systems is in testing its behavior under different environments and scenarios. Being able to set up a virtual network on a single computer and quickly change it seems like it would be extremely useful (although maybe hard to write).
I realize that discovery wasn’t even expected to be implemented until after the quarter and that the one.world development team is aware of its problems, but I figure I would write out a few difficulties that we encountered. Most of our problems with discovery were in stepping on the toes of the one.box team, and vice versa. First of all, it seems like it might be useful if you could set an option to say “run a discovery server if one can’t be found right now” on environment startup. That way, you minimize the chances of starting up more than one discovery server at one time. Also, the discovery server seemed to crash a lot when it seems that all conditions should be recoverable.
In an even more general sense it would be nice if one.world had a way of isolating itself from other one.world instances. For example, say Team A and Team B are working on different aspects of the same project and were required to run and test the same code give or take some debugging changes. Without any configuration changes the two projects could easily step on each other. Of course in the one.world configuration you can change the rep port perhaps to something else for each team, but this doesn’t seem to work entirely. Perhaps if there was a versioning system that could be enabled which only allowed components of a particular version to run with components of the same version this would be cleaner than, say, changing several port constants, discovery server constants, etc…
Status Report for March 7 to March 14
I'm still having a few problems with the election agent. it doesn't always merge quite right. Discovery seems a little more reliable. I think some of my problems was just because I wasn't quite coordinating with the other group on who is running the discovery server or something...
Status Report for February 28 to March 6
Most of my time this week has been learning more about one.world through painful and bitter debugging processes. I'm hoping this next week will be alot more productive.
I'm still having some problems with discovery. It doesn't seem to discover the service every time. I'm just not sure what is going on...
I think that one.world is time consuming to learn when depending solely on the documentation and the tutorial. Understanding exactly what the use of many of the classes or components is or how it interacts in what situations is still fuzzy to me. However, I suppose that these are the flaws of lots of research systems that aren't widely used and documented yet. Files like ServiceMain, SenderMain, ReceiverMain, etc are extremely useful in helping understand certain features of one.world (such as discovery, remote event passing, etc). Some packages (like one.world.rep) also have example code discussing common usages of components in the package. One thing that might be useful would be a frequently asked questions area for some of the classes as well as random snippets of code that demonstrate usage. I realize that there are sections already that have some code examples. Normally when I learn a new API I learn just as much if not more from example programs and tutorials then from the documentation. Obviously more documentation and tutorials takes away from development time, though…
Plans for the upcoming week:
I Had some personal issues to deal with which forced me to take a few weeks off. Before this time, my time was spent: