[dsdp-dd-dev] FW: prototyping against flexible hierarchy API, notes

["Gaff, Doug" <doug.gaff@xxxxxxxxxxxxx>]

Forwarding to dev lists.

-----Original Message-----
From: Pawel Piech [mailto:pawel.piech@xxxxxxxxxxxxx] 
Sent: Thursday, February 02, 2006 8:35 PM
To: Darin Wright
Cc: Gaff, Doug; Williams, Ted
Subject: prototyping against flexible hierarchy API, notes

Hi Darin,
I've been working on a prototype using the new interfaces and i have 
some comments and questions.

_Prototype design (in brief):_
I used the push-down-automata from the debugger tutorial example as a 
back end (for simplicity), and wrote a layer to manage the communication

with the back end.  Like our debugger, this layer is based on a single 
dispatch thread, where all calls to and in this layer have to be made on

this thread without need for other synchronization.  Commands such as 
suspend/resume are handled through dedicated interfaces, and events are 
propagated through a mechanism based on the dispatch thread.  But data 
retrieval is performed through a simple string-based expression protocol

which uses a "model context" object as a token for viewers and actions.
When the launch delegate is executed, it creates an instance of a launch

and the connection layer, but no IDebugTarget instance.  The launch is 
custom, and has a custom model content provider.  The model hierarchy is

populated with model contexts, which are obtained from the connection 
layer by evaluating expressions.  A custom label provider also uses 
expressions to get the labels.  Unlike the standard providers, these 
don't use new jobs to retrieve data from model interfaces, but rather 
they post the requests to be evaluated on the dispatch thread of the 
connection layer. 

_The good:_

    * The content and label providers, and model proxy APIs are very
      well aligned with this design, and I haven't had any issues
      implementing them.
    * The integration between the old and new components is very smooth,
      and I can even have implementations of both working side by side
      talking to the same communication layer.

_Big issues:_

    * My goal with the prototype was to avoid using the synchronous
      interfaces completely, with exception of launch, source lookup,
      and breakpoints.  Unfortunately it turns out that basic debugging
      functionality still depends on them, because the run control
      actions do.  This is something that could easily be address by
      converting them to retargetable actions similarly to run-to-line,
      etc., but with asynchronous APIs.  I don't think this should be
      technically difficult, and I wouldn't mind contributing it myself
      if time was an issue, but it would add a new API to the mix.

_Small issues:_

    * Model-ID is used in various ways by the debugger, like for
      identifying the model presentation, and for
      debugModelContextBinding extension point.  Model-ID is currently
      retrieved through IDebugElement.  Theoretically it shouldn't be
      hard to add IDebugElement implementation to the "model context"
      object, but this interface does have a reference to IDebugTarget,
      which the prototype doesn't implement, and a reference to ILaunch,
      which the model context isn't aware of.  So I wish there was
      another way to associate a model-id with an object, like though
      IAdaptable.
    * Editor positioning and annotation logic is written around the
      IStackFrame interface, so I appreciate the ISourceDisplayAdapter
      interface, I just wish that there was an official way to access
      the standard debugger images.  BTW, ISourceDisplayAdapter is not
      currently accessible because of restriction on
      org.eclipse.debug.internal.ui.contexts.provisional package.


This is all the observations I have so far.  I still have a long TODO 
list for features in the prototype, and I would like to clean it up as 
much as possible before coming to Toronto.

Cheers
Pawel