Re: [platform-core-dev] Re: New marker update API

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

See my <JA></JA> comments below.  It is clear that the original RFC draft
did not adequately define the problem, and it defined the problem too
narrowly.  I have added a new "Motivation" section at the beginning of the
draft that should clear up some of the confusion.



- The ever present threat of premature activation.  Consider plugin X adds
a marker extension wiht some updater class.  Then the marker is put on some
resource.  The workspace is shutdown and restarted.  The resource is then
edited somehow.  If someone calls updateMarker then plugin X will be
activated.  This may or may not be the desired behaviour but it does go
against the model used to date.

<JA>I'm not sure if we can avoid this.  The update algorithm cannot be
described in XML...  If java breakpoints need to be updated in a special
way, then the java plug-in will need to be started.</JA>

-- Potential performance problems.
        updateMarkers() has to be an "operation" as it modifies markers.
If it is called, for example, every keystroke, this would be bad.   Even
though marker modifications do not trigger builds, they would trigger
listener notifications.
        For resources with lots of markers, adding a char at the end of the
resource will still incur the expense of polling each marker whether or not
it wants to update.
        Is there a limit on how much work someone can do in the update
methods?  Edit part of a complex model which affects markers in other
resources...

<JA>Callers of the API would be responsible for being smart about this. For
example, an editor would probably just do updates at "quiet" moments, and
be triggered by edits such as paste, carriage return, etc, with appropriate
batching using IWorkspaceRunnable when large edits occurr quickly (such as
holding down the enter key in a file).  Put it this way: the editor is
already doing these updates manually, so it already needs to be smart about
this... the proposed API is motivated by a desire to move this update code
to a central place, to prevent duplication and to avoid unwanted
dependencies between the plug-ins that define the markers and the plug-ins
that perform the modifications.

- Meta-note:  There has been a tendency over time to try and bend markers
to be many things they are not.  People are best off thinking of them as
generic hashtables attached to individual resources.  That's it.  There is
some delta technology but from the point of view of actual markers and what
they can do this characterization is accurate.

In general the individual usecases supporting marker changes are
sound/interesting but collectively they would make for a very ad hoc and
patchy markers story.  What we are talking about here is enshrining Text
Markers as something special.  Currently there are NO special markers.
There are just a few convenient predefined ones.

<JA>This is one place where the original proposal was misleading.  The API
can be used to update arbitrary attributes on arbitrary marker types.</JA>

Overall summary: Feels like a point solution for a more general problem.
The general case is that resources are changed and deltas generated but
there is no mechanism for describing what the changes were.  For example,
you could imagine that if you were editing a JDOM and add a method, this
information ("method foo() added") would be very interesting to downstream
IResourceChangeListeners and builders.

<JA>The flip side of this is that very general solutions don't always
successfully address specific problems.  The granularity and timing of
resource change events isn't appropriate in all situations.  For example,
it's nice to have your breakpoints and problem markers update as you type,
but you don't want builds and global notifications as you type.  This
comment is partially due to the poor wording of the original proposal... it
described the problem in terms of cases that were too specific.  One area
where I think the proposal may still be too specific is in its description
of the changes.  Perhaps the modifications can be described by some
IAdaptable object that would allow for more detailed edit information if
available and/or appropriate.  I'd appreciate comments in this area... the
trick is come up with something that is general enough to be useful, but
light-weight enough to be useable in practice.</JA>