Re: [platform-core-dev] Comments to "Marker Position Updates"

[John_Arthorne@xxxxxxx]

Thanks Kai, this feedback gives me a much better grasp on the problem.
I'll have to think about this for a bit before taking a second cut at the
proposal.  I have some initial concerns with your suggestions that I have
included below in <JA></JA>.


Kai wrote:


My comments are based on my experience gained with text editors. Text
editors change the content of a file and update all text markers of this
file accordingly. The model is basically the following:

<...snip...>

To me it seems that a text independent solution in core would fit better
with the architecture we already have. Here a raw picture of how it might
look like:
As the original proposal describes, marker updaters can be registered per
marker type. Potentially more than one per marker types are allowed as long
as the attribute sets manipulated by these updaters are disjoint. IFile
does not provide an updateMarker method. Instead on setContent and
refreshFromLocal all marker updaters are called. A called updater gets
access to the new and the old content of the resource. Additionally, it
gets the marker as parameter. There must be a way for updaters to indicate
that a marker gets removed or stale in result of the updating.

<JA>The old content is not available after refreshLocal.  The user has
wiped the content out from underneath us before the refresh method is
called.  In the setContents case, this approach would have serious
performance implications.  Since setContents is just given a stream, we'd
have to read the entire new file into a memory buffer or to a temp file.
Then each marker updater would have to compute a naive diff on the content
and recompute marker positions accordingly.  As you said, files can easily
be quite large.  setContents can be called very often, and some major
operations such as builders can do thousands of setContents operations at
once... I don't think we can afford such a heavy marker update strategy
every time setContents is called.

The reasoning I followed in writing the proposal was: if a client can
provide detailed edit information (such as the replace commands you
mentioned), then marker updates could be done quite efficiently.  If such
information was not available, the user would just have to live with their
markers being in the wrong place.  It may not be ideal from a user's point
of view, but this is a tradeoff between functionality and performance.

 </JA>

This way, each level can install updaters for the marker types it
introduces or knows of. The text infrastructure could provide text marker
updaters leading to the nice-to-have request of dynamic registration and
unregistration of marker updaters. An editor, e.g., could temporarily
register itself as marker updater as it already knows the new position of
the markers. In addition, a more general text marker updater, e.g., could
diff the new and the old content and use the diff for adapting markers.
Right now, this does not solve the headless case yet - but it shows the
need for a headless text infrastructure.