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