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

[Jed Anderson <jed_anderson@xxxxxxxxxx>]

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




  
                      Jed   
                      Anderson/Minneapolis/IBM        To: 
platform-core-dev@xxxxxxxxxxx 
                      @IBMUS                          cc:     
                      Sent by:                        Subject: 
[platform-core-dev] Path variable resolution 
                      platform-core-dev-admin@    
                      eclipse.org   
  
  
                      01/17/2003 05:13 PM   
                      Please respond to   
                      platform-core-dev   
  
  




Am I required to call IPathVariableManager.resolvePath(IPath) on a path
before calling toFile()? The implementation of Path.toFile calls
toOSString, which does not use the IPathVariableManager at all.

If this is the case, I will open a bug noting that the documentation on
IPath should be updated to reflect this new API agreement.

Are path variables a generic implementation of the JDT path variables?
What sort of assumptions should I make about path variable
creation/deletion frequency and total number of path variables?

jkca





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