Reborn from the ashes...

I had given up on updating this blog because I thought no-one was reading it. To my surprise, however, we have at least two readers! One of them even subscribed to my RSS feed! Wow! I'm no longer a lonely looser!

Anyway, that's more than enough reason to get this blog up again. I have made significant progress since my last post, and now we even have a couple of screenshots at my website at Eclipse@IME to show off.

As you may probably be aware of, I am developing a distributed debugger for Eclipse. This distributed debugger is actually a composition of other debuggers - and these debuggers are, in turn, symbolic debuggers based on an extended version of the Eclipse debug model (extended for distributed debugging). The distributed debugger may also be seen as a core under which these extended symbolic debuggers will run. I am going to provide, for starters, an implementation of a simplified Java debugger (that can be plugged into the core). I hope I can run the JDT debugger instead of mine one day, however.

What people seem to be missing from what I'm doing, however, is the fact that my debugger isn't just a collection of independent symbolic debuggers running toghether - the Eclipse debug framework already provides that. My debugger implements the concept of a distributed thread to capture and reveal causal relations between the nodes of a distributed system. It also does neat things like remote process management and stream forwarding, but its main point is capturing causal relations and showing them in a meaningful way.

So, how do I do that? Well, as mentioned earlier, I show the distributed system as a collection of distributed threads. What the heck is a distributed thread? A distributed thread is that thread of control that you can mentally picture going into a remote object proxy and popping at the matching remote object when you use RPC/RMI middleware like CORBA or Java/RMI. Simple enough, huh?

Oh, man, I am bulging with new ideas. And I am definitely working on a collaborative debugger that Scott Lewis suggested as well.

And then I'm going to get a nice RSI from coding so much.

...

Time for bed.