This is the Debug Model Sub-group
Lead: Pawel Piech (Wind River)
Members: Mikhail Khodjaiants (QNX), Freescale, Nokia
- 1 Requirements discussion
- 1.1 Introduction
- 1.2 Citizen monitoring system in George Orwell's 1984
- 1.3 Debugger for the citizen monitoring system
- 1.4 Connectivity between debugger and monitoring system
- 1.5 What debug data should be presented and where
- 1.6 Update policies for debug data
- 1.7 Filtering and sorting of debug data
- 1.8 Interoperability with other debuggers
I really don't know how it's possible to start a requirements discussion without having a specific problem or use case to be solved. What generally happens in these situations, is that a set of adjectives are listed that are so un-specific that they are impossible to take an action upton: "scalable", "flexible", "responsive", etc. On the other extreme, if everyone comes to the table and describes their specific problem that they are trying to solve, the discussion tends to drift towards completely irrelevant topics and often goes to try to solve conflicting problems that aren't even in the scope of the original architecture.
So I propose a third approach to this discussion, which I think might be a lot more fun than describing intricate details of everyone's debugger. Let's define a completely theoretical debugger problem, one that we can use to represent all of the different types of problems that we have to solve for our very different debuggers. We don't necessarily have to try to roll all of our different and sometimes divergent problems into one theoretical model, we could have many different versions of the model, and then try to apply our solution to fit these different needs. As we introduce features into this model, we could tie these into specific requirements that we already have defined for our products. Hopefully this will be a lot more fun than a traditional technical discussion.
Citizen monitoring system in George Orwell's 1984
For those unfamiliar with the book, in 1984 the citizens of Oceania live under the constant watchful eye of the Party and its leader Big Brother. The Party has mandated that all citizens have a telescreen installed in their private homes, as well as in all public spaces in Oceania. The telescreens are both a camera through which a party official could be looking, and a display monitor through which messages could be sent to the individual citizen.
Designing the monitoring system was a formidable task, Oceania is a huge nation of hundreds of milions of citizens, and only 15% of this population are members of the Party, and of those 15%, only a small fraction are in the Inner Party who are trusted enough to be monitoring citizens and other Party members. So most of the work of the monitoring system falls onto the automated monitoring system, based on the latest microprocessor designs no doubt, which looks at everyone through all telescreens all the time and watches for signs of thoughtcrime.
Debugger for the citizen monitoring system
We would like to design a debugger which will help us debug the telescreen monitoring system within our Eclipse-based debugger. And based on the information so far, we can already draw up some requirements that our debug model will have to meet:
- There should be no assumptions about the number of objects that the debugger might need to track. In Oceania, there are hundreds of millions of citizens and there are just as many telescreens.
- The debugger views need to be able to rely on the external debugger process to perform filtering and sorting of the data to be presented to the user. There is a powerful database computer somewhere deep within the headquaters of Thought Police, that performs the tasks of sorting, filtering lists of citizens, there is no way that a simple PC could store this much information, much less to process all of it.
Connectivity between debugger and monitoring system
We know for certain that the citizen monitoring system is an extremely distributed system; there are hundreds of millions of monitoring screens, which are connected to hubs which are then connected to the central monitoring computer. But as far as how the debugger is connected to the system we are starting to have a few options:
- We may have the priviledge to actually install Eclipse on the central monitoring computer and be able to debug the system on the local host.
- More likely we will not have the priviledge to sit at the precious central monitoring computer that is running deep within the headquaters of the Thought Police. Instead we will have to be at some remote computer connected over ethernet of DSL, or maybe dial-up, and our debugger will be communicating to an agent application that is running on the central monitoring computer which is directly controlling and inspecting the monitoring system.
- Another possibility is that the debugger will have to communicate both with the central monitoring computer and the multiple hubs or even to the individual telescreens to retrieve specific detailed data from the system.
Given these different possibilities, the corresponding debug model requirements are as follows:
- Debug model implementation should be able to communicate with a back end over a slow connection with a large latency.
- But for local host debugging, It should also be able to communicate over a very fast connection without loss of efficiency.
- There should be no assumption that there is only a single connection to the back end, because the debugger itself might be distrubted in a distributed system.
- It should be able to communicate over a very un-reliable connection, where the connection might be lost, then later recovered, and the debug model should be able to re-synchronize itself with current state of data on the debugged system.