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

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

------------------------------------------ 
*        I disagree with Jeff's meta note - In my view markers are what users perceive them to be.  If we see opportunities for improving them to provide better user functionality then we should. Convincing all the clients its just a hash table and to live with it is not a useful activity and will probably just frustrate our clients. While I am not sure I agree with this proposal, I would caution against this general view of "just live with it".. Jeff if I misunderstand I apologize, but since I'm a client I thought it important to point this out. I will agree that we should not add behavior/api as point solutions without thought - which is exactly what this design prpoosal approach gives us. 

<jm>
Actually you are agreeing.  I never said "just live with it" (don't know where you got the quote).  My point is that the markers mechanism is a general one.   This is key to its sanity.   If there are general ways of extending this functionality, great.  Extending the capabilities of markers in a point-wise manner is less than optimal.  
</jm>

------------------------------------------ 
*        The implication from Jeff's reply is that irrespective of whether or not we have an updateMarkers that if an editor simply wants to update markers on keystrokes (or at quiet points) this would be bad because they get wrapped in operations. This seems problematic to me.  It should be possible for editors to light-weight update editors (especially if the claim is they are just hash tables<g>). 

<jm>The operations are necessary because a notification change (i.e., delta) lifecycle is required.  As I pointed out in the post, "...marker modifications do not trigger builds".  I also did not say they are "just hash tables".  I said "People are best off thinking of them as generic hashtables".  This is the mindset intended, the implementation is a different story.
</jm>

Jeff