Community
Participate
Working Groups
When reviewing the API for IMetadataRepository, it was noticed that only one method takes an IProgressMonitor as an argument. (#removeIUs) We need to be consistent and either remove it or add it to other methods. Note that if we decide to add it then we also need to think about adding it to the property set methods as well. (name, description, etc)
A related observation is how progress monitors are used in IQueryable.query(). Most of the methods does not use it all. All in all, it's more or less impossible to determine how long a query will take and how far it has progressed. It would be feasible to start a query by asking for a monitor with IProgressMonitor.UNKNOWN. The expression evaluator could then tick this monitor and check it for cancellation on a regular basis until the query is complete. That would mean that no monitor needs to be passed down to the actual evaluation methods (this would slow things down significantly). Instead, the monitor can be kept in the evaluation context. No "progress" is reported, but at least there would be an indication that it is alive and can be cancelled.
Please let's keep the discussion focused. There is already a bug about reporting progress monitoring in the context of query https://bugs.eclipse.org/bugs/show_bug.cgi?id=249670.
I think we should just remove the progress monitor argument from the removeIUs method at this point, rather than adding it to all other modifying methods. Currently our API design assumes repository modification is fast (i.e., only local repositories are modifiable). If we branched out into modifiable remote repositories we would likely want different API for executing a set of changes all at once. For example, instead of: repo.addIUs(...) repo.removeIUs(...) repo.setDescription(...) Where each method results in a round trip, we would want some kind of batching mechanism to make the communication more efficient: repo.executeBatch(new Runnable() { public void run() { repo.addIUs(...) repo.removeIUs(...) repo.setDescription(...) } }, progressMonitor); I don't think this is something for 3.6 as we don't currently have any mutable remote repositories, but just illustrating why adding a monitor to every single repository mutator method likely isn't the best approach.
I agree with John. I released the change for this as part of my patch for bug 303269. The new API removes the progress monitor. Closing.
