[platform-compare-dev] Compare Issues

["John Arthorne/OTT/OTI" <John_Arthorne@xxxxxxx>]

I've just joined the list, so this reply won't be threaded correctly.  I'm
replying to Andre's e-mail that asks the question, How is "Compare/Merge
with Stream/Version/Patch/Each Other" presented?

I think the most important thing to point out here is that it shouldn't be
the compare framework's job to mandate how all compare/merges should
appear.  A significant problem with the existing framework is that it
assumes all compares/merges will occur in editors.  The CompareEditorInput
is the central element in the model, and this design makes it extremely
difficult to go with a non editor-based solution later on.

This got us into a lot of trouble in the catchup/release implementation.
Due to a number of usability problems, we decided to move from an editor to
a view at a late stage.  Since the framework wasn't designed for this, we
were forced into a hacked, ugly sync view implementation.  We cannot
predict what future ISV tools might want to do with the compare framework.
I would like to see the compare framework just provide basic building
blocks:

- compare viewers, structure and content viewers
- differencing tools and algorithms
- A Composite such as the one currently created in
CompareEditorInput#createContents
- compare-specific preferences, actions, configurations.

The idea would be that an ISV could use these building blocks to quickly
create compare/merge presentations however it makes the most sense for
them: in editors, views, dialogs, etc.

I understand the desire for a consistent compare/merge story, and it may
turn out in the end that most of the platform and Java tooling
compare/merge presentations appear in the same type of UI.  However in the
interest of flexibility and extensibility, this decision should be in the
hands of the clients of the compare framework, and not be predetermined.