Re: [platform-debug-dev] Source Lookup Path proposal

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

Thanks for the design proposal. Overall, the goals and the proposal are in synch with what we'd like to acheive with regards to generic source lookup facilities in the debug platform.

Here are my initial comments.

* Terminology

- Rather than use the term "Source Location Manager" (ISourceLocationManager) to describe the root source locator that manages contributed (model specific) source locators, I propose that we use the term "Common Source Locator" (ICommonSourceLocator). I realize this is confusing, since you have used the term "ICommonSourceLocator" to describe a participant in the source lookup scheme. I'd like to call each participant (model specific source locator), an ISourceLocatorParticipant. Thus, there would be an implementation of CommonSourceLocator provided in the debug platform that manages a set of source locator participants, which are contributed by each launch config type that uses the generic source lookup facilities. Note: in the debug platform, we have used the term "manager" to refer to global managers like the "breakpoint manager" and "launch manager"  - thus I want to avoid!
  using the term "manager" for something that there are many instances of.

- For similarity with other extension points in the debug platform, I'd like to use the "type pattern" (Gamma, et al) for source locations. Thus, a "source location factory" would become a "source location type", of which there can be instances. The type is responsible for creating instances and persisting instances (mementos). The net result is renaming ISourceLocationFactory to ISourceLocationType.

- Rather than having two extension points for the GUI components of a source location type, I'd recommend one "sourceLocationPresentation" extension point containing attributes for an "icon" and "browser".

* Implementation

- The ISourceLocationType should be responsible for generating mementos for its source locations, and re-creating source locations from mementos. This provides more flexibility on the underlying implementation classes (i.e. the source location implementation class can change - only the factory needs to know what class is to be used). The implementation could have the source location generate mementos if desired - but that can be an implementation detail.  Thus, the methods getMemento() and initializeFrom(..) would be moved to ISourceLocationType. As well, an ISourceLocation would have an accessor method to get its associated ISourceLocationType. The methods that create/restore source locations/mementos should be allowed to throw exceptions in case of currupt mementos or unsupported source locations.

- Generally, API interfaces should not have setters for things which are retrieved from XML - for example ISourceLocationType.setLocationName(...) and setLocationID(..). Instead, the setter methods are only defined in the implemetnation classes which are internal. Somewhere, we will need a manager to load/maintain the initial set of contributed source locations types. Since the API is small (i.e. getSourceLocationTypes()), we may be able to add this to something like the launch manager.

- Rather than having an IDefaultSourceLocationComputer, I suggest that there is an "ISourcePathComputer". The method defined on this interface would be "computeSourceLocations(..)" given a launch configuration. (This should also accept a progress monitor in case the computation is expensive). I don't think there is a need for the method "isDefaultSourceLocation" on ISourceLocation. Rather, an implementation of DefaultSourceLocation in the debug platform can be instantiated on a launch configuration. The configuration's associated source path computer will be queried for its default source locations, and be stored as children of the default source location. The "default" children are never stored explicitly in mementos - rather the default source location has a memento, and it regenerates its children lazily when queried. The tricky part is to know when the children might need to be re-computed. For ex!
 ample, the source path computer for a Java application computes a source path based on a project's build path (or config's runtime classpath). When the build path changes, so should the source lookup path. Thus a source path computer may need a lifecycle. It should be created on a launch configuration, and disposed on completion. This way the source path computer can listen to changes in the config (or whatever it needs to do), and update as required.

- Currently, the propsoal states that each source locator must take care of handling of duplicates. I think the common (root) source locator should handle this. Otherwise, each source location participant could prompt the user for duplicates (which could result in multiple dialogs when searching for one source element). As well, it would be beneficial to centralize the selection dialog. Thus, I think an implementation of ICommonSourceLocator would be defined in the debug UI to handle this. As well, an ISourceLocatorParticipant would not extend ISourceLocator - the API instead would return for multiple source elements - i.e. findSourceElements(IStackFrame frame, boolean duplicates).

* User Interface

- My main concern here is the "double dialog". That is, a user has to go through several layers of dialogs to add a source location. First they must choose the type of location to add, and then configure the selected location type (for example, choose the project(s) to add). I'm not sure what we can do about this since source location types are extensible, and the number of buttons on the source tab would not be fixed. However, we should consider how we might be able to simplify this.

* Proceeding

- To proceed, I suggest that I take the interfaces/extension points you have provided in your proposal an integrate them into "internal" packages in the debug platform (HEAD, 3.0 stream). You can then provide (contribute) an implementation based on the interfaces (and comment on the interfaces). Once we have things working, we can promote the interfaces to API.



Darin

Kristen Desarmo/Toronto/IBM@IBMCA Sent by: platform-debug-dev-admin@xxxxxxxxxxx 11/20/2003 12:17 AM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-debug-dev] Source Lookup Path proposal

The attached document outlines a proposal for source lookup that will be contributed to Eclipse 3.0. The goal of this solution is to create a common source lookup mechanism that will make implementing source lookup easy and consistent for all debug adapters.  Please respond to this mailing list with any comments, questions, or suggestions. 

(For those who have seen earlier drafts of this document, the major additions are default source location support and the concept of a source location having visible child source locations.) 



Thanks! 

Kristen Desarmo
Debugger Development
IBM Toronto Lab
 



#### SourceLocation.doc has been removed from this note on November 27, 2003 by Darin Wright