In our remote debugging protocol client, packets arriving from the server all go through DC_onPacket. That function manages request/reply-style interactions, but also has special cases for the more complicated exchanges with thread actors. As other patterns appear in the protocol, DC_onPacket will become unweildy. Instead of having a single piece of code that understands all actors' patterns of communication, we should have a distinct client-side JS object acting as a 'front' for each actor. A front would be responsible for making sense of its actor's state, and providing a reasonable interface for UI widgets to interact with. The front will be the only thing that sends messages to its actor, and the front will handle all messages from the server for its actor. DC_onPacket should simply forward packets to the appropriate front. We should create fronts only on demand. For example, the stack frame for a function call has a callee; the front for the stack frame should avoid creating a front for the callee until someone actually asks for it.

I think this makes sense. I want to call this Front object a Stage. Also, the summary describes a "Front" for each actor. Is this the case or should we have a single front/stage object that knows about all the actors?

The intention is a frontobject-per-actor. Actors are objects, it feels more natural to let the client treat them as such by giving the client objects. We also have been throwing around the idea of a special jsclass that we can use to notice when a front object is no longer in use, and send a 'release' request to the server if one hasn't been sent already.

After protocol.js the plan have changed. I think we should morph this bug into a "convert our old-style actors to protocol.js" bug. Bug 910141 is about starting with the ObjectActor, and after that we can proceed with the rest.

Note that old actors include the web console, profiler, tracer and webapps actors, too.