[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
