Thanks again for the update.
1) DSF is very heavily based on the asynchronous viewer and APIs.
Therefore a advance notice of when the switch would happen would be
helpful.
2) Another provisional API is certainly not ideal, but the prospect of
a common viewer used by both Common Navigator, debugger, and others, is
certainly worth the wait.
For Wind River's commercial product, we use some of the flexible
hierarchy APIs already and we're planning to use DSF in our next
product release, so we're pretty much married to them. But we're also
committed to update our product with each eclipse release, so we can
react to API changes as needed.
Pawel
Darin Wright wrote:
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
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
|
