[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-dd-dev] Custom debugger integration: flexible hierarchy andasynch viewers
|
Some of the CDT debugger components are based on the
internal Platform API. The CDT community is aware of it and our HEAD branch
is compatible with the current milestone of the Platform HEAD branch. Of course,
the advance notifications and comments are highly appreciated.
Currently, it is not easy to get this information without
monitoring the bugzilla or participating in the DSDP monthly
calls.
Mikhail
Khodjaiants
ARM
Ltd.
Debug community,
During the 3.2 release, the debug platform
developed and released new infrastructure to support flexible element
hierarchies in the debug viewers. As well, content and label generation for
elements in the viewers was moved to background (non-UI) threads and supported
cancellation. This infrastructure has been instrumental in allowing the DSDP
project, its participants, and other debug ISVs to utilize the debug platform.
In 3.2, the support was released as internal framework, with the disclaimer that
anyone who used it would be broken when the framework evolved to its public
form. For 3.3, our goals was to
publish the framework as a public API. In doing so, we've improved the
implementation (in a branch) to leverage the JFace viewer code base. As well,
we've confirmed that the viewer implementation is generic and should not live in
the debug platform. Others would like to use the framework for non-debug
purposes. Ideally, we'd like to find a home for the viewers outside of the debug
plug-ins. We'd also like to ensure that we're not duplicating efforts/APIs. To
find the right home for the framework and ensure that we have consistent APIs
and functions in the Eclipse platform may take longer that the 3.3
release. We don't want to publish an
API in the wrong place. So, if we can't find the right home for the framework,
we'd like to keep the framework as an internal implementation for 3.3. We don't
want to cause unnecessary pain for those that are already using the framework.
At the same time we'd like to use the improved implementation in 3.3.
So the questions for the community
are: (1) Who will break if we change the
internal implementation? (Our feeling is that not many are actually using the
3.2 internal API yet, except for experimentation) (2) What are the implications if we provide a different,
but internal implementation in 3.3? Thanks, Darin
Wright
--
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
