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

["Jeff McAffer/OTT/OTI" <Jeff_McAffer@xxxxxxx>]

There are a few issues...

- 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.

- 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...

- 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.

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.  

Historical note: Way back when we had a mechanism called "annotations" which allowed for some degree of this functionality.  I am not proposing that annotations be revived but thought I would mention it.

Jeff

"John Arthorne/OTT/OTI" <John_Arthorne@xxxxxxx> Sent by: platform-core-dev-admin@xxxxxxxxxxx 11/30/2001 10:03 AM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-core-dev] Re: New marker update API

Craig, thanks for the input, these are good questions.  My problem in
writing the RFC was that I'm not really familiar with how people are
currently using and updating markers.  It is possible that at least a
method for supplying a batch of changes to a given file would be
appropriate.  I hesitated about this, partially because I didn't want to
introduce a new object to represent each change.  Since each file will
change in a unique way, I don't see an advantage of having a single API
method that groups changes from many files.  For your info, there is
already a generic mechanism for batching together a set of calls to the
core... see the API comments on IWorkspace#run, and the interface
IWorkspaceRunnable.

The timing of when marker updates occur would continue to be driven from
outside core (i.e., the UI). Clients could decide to batch up a set of
changes, and then ask core to process all the marker updates at once, or
they may prefer small incremental updates.  This is a bit different from
the resource delta updating, which happens "automatically" from within core
as a side-effect of other API calls.

Again, thanks for the feedback!




                                                                                                                    
                    Craig Miskell                                                                                   
                    <cmiskell@xxxxxxxxxxxxxxx        To:     "platform-core-dev@xxxxxxxxxxx"                        
                    >                                <platform-core-dev@xxxxxxxxxxx>                                
                    Sent by:                         cc:                                                            
                    platform-core-dev-admin@e        Subject:     [platform-core-dev] Re: New marker update API     
                    clipse.org                                                                                      
                                                                                                                    
                                                                                                                    
                    11/30/2001 05:51 PM                                                                             
                    Please respond to                                                                               
                    platform-core-dev                                                                               
                                                                                                                    
                                                                                                                    



Disclaimer: I'm new to the whole eclipse thing... I've been lurking,
reading, and observing, but yet to play an active role, and I'm not
intimately familiar with any of the code, just a vague overview.  If I'm
out of line, or say something really stupid, a gentle slap would be
appreciated.

Right, down to the RFC:
The proposed API looks reasonable to me - it's simple and to the point.
But as I read it, the following jumped out at me:
"The update should be light-weight and as fast as possible. These updates
could
potentially occur after every user edit, or during a large batch of
refactoring
changes"

and then the API proceeds to be a method for each individual change.
Would it not be better (trickier, but better) to allow multiple changes to
be coallesced into a "Delta", much like is done in core.resources.  A
given marker extension could register either for coallesced updates or
individual updates, depending on the nature of it's markers.  This gives
the flexibility of getting each notification individually if required, or
the performance advantage of a bulk update when feasible.

I don't know if this fits with the general UI direction of eclipse
(perhaps not a subject for this list), but this could also then support a
user turning off marker updates for a period of editing, if they're on a
slow machine, or editing a complex bit of data that would just be painful
to update markers "on-the-fly".

Does this gel with anyone else, or am I missing the whole point?

Craig Miskell



_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev