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

[Kai-Uwe_Maetzel@xxxxxxx]

Comments to some issues that came up in the discussion:

- Performance versus functionality, i.e. the core cannot afford an
expensive marker update story:
Marker updating might be expensive, but there is no implication that it
must be expensive. For example, marker updaters could consider problem
markers transient. This means that the updaters would remove the problem
markers rather than changing their attributes. In order to find out what is
expensive and what not, there should be an explicit assumption about the
frequency and the characteristics of markers. If the assumption is that
there are mostly transient markers (see above) and that non-transient
markers are only sparsely attached to resources, updaters would be called
rather infrequently. (They are only called for resources that have
markers.)

- Diffing is too expensive:
As the proposal says, diffing would be the most general approach taken if
no other approach would be possible. In most cases more specialized and
optimized approaches could be taken. E.g., editors, as proposed, could
register as updaters and would exactly know the new marker positions.
Providing access to the new and old content must not be part of the updater
mechanism. Updater just need to know how to access the content. This would
allow for fetching the content only when it is needed.

- There is no access to the old content:
In general this is true. Nevertheless, if a file history is kept, the
former content could be retrieved from the history.

- Early plug-in activation:
If the platform needs plug-in specific code to update a plug-in specific
marker, this could should be loaded. Btw, if a resource has a plug-in
specific marker attached to it, one might speculate about the probability
that functionality of this plug-in is used in a rather short temporal delta
around the point of  updating the content of the resource.


For me the most important question is not whether the update mechanism is
expensive or not but whether it is sufficiently powerful. A insufficiently
powerful update mechanism  is questioning the concept markers as a whole.
More correctly, markers would be transient by definition and then the API
should appropriately reflect this. "...the user would just have to live
with their markers being in the wrong place." might be acceptable from the
core's perspective, but does not make a consistent user story yet. Thus,
the core would forces the UI to guess about the marker updating because
invalid markers are usually unacceptable for the user.

Kai