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

[John_Arthorne@xxxxxxx]

I'm still not convinced about the performance implications.  With my core
hat on, I cannot forsee what future uses of markers might come up.
Plug-ins could quite possibility have a need for placing large numbers of
text markers in large files, and it seems inappropriate to enforce a
heavy-weight marker update story (possibly requiring expensive diffs) every
time setContents is called.

I'd like to try refocusing the discussion by defining the problems were are
trying to solve.  There are two sets of entities involved, the things that
modify files (I'll call them "editors" for simplicity, but this includes
headless file manipulators), and the things that know how to update the
markers in those files (I'll call them "updaters").  As I see it, here are
the goals of the proposed core API:

1) Decouple the "updaters" from the "editors".  Updaters don't want to
"know about" or have references to any editors, and vice-versa.  This
allows reuse of the marker updater mechanism by any number of editors,
either UI or headless.

2) Provide a mechanism for editors to pass relevant information to the
updaters, so that marker updates can be done efficiently.  The idea is that
the editors already have a good idea about what has changed, and passing
this information to the updaters would allow updates to be done very
quickly (i.e., without parsing/diffing files).

Based on your comments, you seem to be suggesting that most of the time the
editor IS the updater.  This means the above two goals are not interesting,
and the sole reason for the Core API is to hook in a naive marker update
for the rare case where the editor IS NOT the updater.  A hook in
setContents doesn't solve 2), and only solves 1) in the naive update case.
What I was trying to come up with was an API where generic sets of editors
and updaters could exchange the information needed to update markers
efficiently.

I didn't mean to suggest that users have to accept markers being not
updated. What I meant was this: if we provide a marker update mechanism
that allows for efficient marker updates, and some editors don't make use
of it (which is what the setContents hook tries to solve), then I suggest
we don't try to handle it.  Responsibility would fall on the editors to
make use of the marker update mechanism, and if they didn't use it, it
would be their fault that markers were out of date.





                                                                                                                    
                    Kai-Uwe_Maetzel@xxxxxxx                                                                         
                    Sent by:                         To:     platform-core-dev@xxxxxxxxxxx                          
                    platform-core-dev-admin@e        cc:                                                            
                    clipse.org                       Subject:     Re: [platform-core-dev] Comments to "Marker       
                                                     Position Updates"                                              
                                                                                                                    
                    12/10/2001 06:31 AM                                                                             
                    Please respond to                                                                               
                    platform-core-dev                                                                               
                                                                                                                    
                                                                                                                    




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.

<...snip...>