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

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

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

Hi Darin,
Thanks for the quick response, please see below.

Darin Wright wrote:
>
> Hi Pawel,
>
> Thanks for the constructive feedback. I hope we can leverage your 
> experience in our talk at EclipseCon.
>
I hope so as well :-)
>
> >
> > _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.
>
> This is good news :-)
>
> >
> > _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.
>
> Correct - the control actions use the existing IStep, ITerminate, 
> etc., interfaces. Although these APIs are synchronous, they are 
> non-blocking. So I need to further understand what the issue is here. 
> For example, the step over action simple gets the IStep adapter and 
> calls "stepOver". The implementation of the IStep.stepOver() should 
> initiate the step, but should not wait for the step to complete. The 
> step completes at a later time, and is indicated by the model proxy 
> firing an appropriate delta. I think the only issue here is that there

> is no way for the model to indicate failure (via a request monitor), 
> if the failure happens after the step is initiated. So, it's a synch 
> API with asynch behavior.
>
> Since the actions simply initiate the function (step, termiante, 
> etc.), and then update based on model deltas, I'm not sure what we 
> would gain with an async API. The actions currently don't need to know

> when the function completes.
>
> Although we could put async UI wrappers/adapters on the functions, my 
> belief is that you should still be able to have an async 
> implementation with the existing interfaces.
>
When it comes to having action adapters vs. interfaces, it's more a 
question of efficiency in updating the action state more than anything 
else.  I think I need to explain a little more on how we implement these

interfaces:

The the "model context" objects that are returned by the content 
provider are immutable tokens which are used as input to various methods

in the connection layer 
(canResume/Resume/canSuspend/Suspend/canTerminate/Terminate/etc.).  But 
the connection layer operates on the single dispatch loop, so whenever a

synchronous data request is made, such as canResume(), the calling 
thread is blocked while the request is evaluated on the dispatch 
thread.  I noticed that when a selection is made in Debug view, multiple

jobs are started (one for each action), all which just end up being 
blocked waiting for the single thread to service the requests on the 
single dispatch thread.  Some actions (e.g. resume), call the 
canResume() multiple times, invoking a separate dispatch each time.

With retargetable actions, I was hoping that we could handle these 
updates the way we handle view updates with flexible hierarchy 
interfaces.  Then we wouldn't need a separate job to be started for each

action on each state update, and if multiple tests needed to be 
performed, they could all be done in a single dispatch.
> >
> > _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.
>
> Do you know where we are using the model ID from IDebugElement? In the

> latest code base we are trying to be clean. The view binding stuff 
> does use it, but I have a new implementation waiting to be released 
> (pending a workbench bug), that is based on the debug context manager,

> and the IDebugModelProvider adapter. So, we do have an adapter for 
> this, and we should be clean with respect to using it. Please file 
> bugs where you find problem areas.
I just assumed that the model ID is something that is required for a 
well functioning implementation.  The only place where it became an 
issue during the prototype, is when I was trying to add the source 
lookup and editor positioning logic, but like I said, that's something 
that can be done through the adapter.  If I see any real issues, I'll 
create a bug.
>
> >     * 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.
>
> Right, our standard "source display adapter" is based on stack frames.

> We've added IInstructionPointerPresentation in 3.2 (enhanced for M5), 
> but it is intended to be used with the "standard model". Are you just 
> looking for public image access - currently the instruction pointer 
> images are internal, but could be made public (there Ids are in 
> IInternalDebugUIConstants - IMG_OBJS_INSTRUCTION_POINTER and 
> IMG_OBJS_INSTRUCTION_POINTER_TOP. If you can envision helpful API 
> here, please file enhancement requests. (Note, at this time we're 
> under the gun to freeze public API (Friday Feb 10), in preparation for

> M5).
>
This is not a bid deal, since it's not hard to copy an icon, but for 
long term maintenance I think it would make sense to put 
IInternalDebugUIConstants and DebugPluginImages in a public package.  
I'll file a bug on it for, but if you decide against it that's fine too.

Cheers
Pawel
> >
> >
> > 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
> >
>
> Darin Wright
> Eclipse Debug Lead,
> Rational Team,
> IBM Canada
> (204)934-4114