Re: [platform-core-dev] Path variable resolution

[John_Arthorne@xxxxxxxxxx]

Hi Jed, it's definitely not too late to add batch-oriented API for path variable changes.  However, I'm not yet convinced about the use cases for changing many variables at once.  The platform handles serialization of the variables, so setting many values on startup isn't likely (except perhaps the very first time a plugin registered some variables).  Having said that, it's hard to predict how clients might start using path variables, so it might come in handy in the future.  Feel free to enter an enhancement request against platform core for this.

In the meantime, I think your simple update strategy will work fine.  You can get a bit fancier and compute exactly which resource locations are affected by the variable change without too much work.  Calling getRawLocation() on projects and linked resources will return a path with the path variable unexpanded.  You can then match the first segment of these paths against the change variable to see if that resource was affected.  Since a given resource can only be associated with a single path variable, this approach would have similar efficiency in batch and non-batch scenarios.
--

Jed Anderson/Minneapolis/IBM@IBMUS Sent by: platform-core-dev-admin@xxxxxxxxxxx 01/17/2003 06:14 PM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-core-dev] Path variable resolution

Glad to hear that IResource.getLocation returns the resolved path.  That 
greatly simplifies my life.

I ask about frequency/volume because I want to do brainless processing of 
the change events in the Autorefresh support.  The basic idea is that I 
need to make sure that the Autorefresh support is monitoring the correct 
files.  I will have to remove (& add) native hooks for each IResource 
who's path changed because of the variable change.  Since these are native 
calls, a bunch of changes could be expensive .  However, the easy solution 
is to remove all and then add all each time a call comes in.  This, of 
course, adds up to a bunch of changes (in the lots of projects, lots of 
linked resources case).  If I could guarentee that many edits to the path 
variables wouldn't occur in a short timeframe, I would use this solution. 

But the API is set up to notify listeners on _each_ variable change.  This 
means that even if a client could notify the IPathVariableManager of many 
changes all at once, it wouldn't be able to.  This forces each listener to 
process multiple events instead of just one big one (which in my 
experience tends to be less expensive).  Is there any possiblity of 
changing the API to support a more batch oriented approach? 

Maybe you need some convincing? :)

Example 1: I can only assume that when the JDT starts using this support, 
they will register all of their path variables on plugin startup.  In my 
current workbench there are eight CLASSPATH variables defined.  This means 
they will set each of the eight variables individually.  This will cause 
eight callbacks in a very short period of time.  If the 
IPathVariableManager was set up to accept many changes at once, you could 
send out batch notification.  It seems likely to me that other plugins 
will set their variables in bunches.

Example 2: The debug event model.  In the 2.0 release, all events were 
sent individually.  This forced their UI to process each event 
individually, and caused many slowdowns (e.g. remove all terminated 
launches).  In 2.1 they released an addendum interface that allowed 
clients to register multiple events at once, and the listeners to recieve 
many events at once.  This allowed them to optimize many cases.

jkca



John_Arthorne@xxxxxxxxxx
Sent by: platform-core-dev-admin@xxxxxxxxxxx
01/17/2003 04:35 PM
Please respond to platform-core-dev

 
        To:     platform-core-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-core-dev] Path variable resolution



Paths are not aware of variables at all.  Paths are in the runtime plugin,
and path variables are in the resources plugin, which precludes any
possibility of interaction from IPath->IPathVariableManager (even in
javadoc).  What path are you calling toFile() on?  IResource.getLocation()
will return a location that is already resolved.  If you call
IResource.getRawLocation(), then you will have to resolve the path
yourself.

Path variables are similar to JDT build path variables, and they could
potentially replace them, but they are not connected in any way.  Why do
you ask about create/delete frequency, etc?  I can't really say, but I
expect they will be created with similar frequency as JDT path variables.
My guess is that they will be created rarely (only when the project is
first setup), deleted very rarely (no interesting use cases for this).  As
for quantity, I expect a small number... a high figure would be 10 or 20?
You can read the following document to find their motivation, and some use
cases.

http://www.eclipse.org/eclipse/development/flexible-projects-proposal.html