[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Minutes Indexer Call
|
I am open to trying different approaches as well. We can always do a bit
of prototyping and see what the performance is actually like. The term RCP
is a very loose one and sometimes people get different notions of what it
means.
We definitely won't be operating in a vaccuum. We'll let you all know what
we're up to. If we end up making some very large changes we will probably
try doing that work on a branch so we don't destabilize things too much.
That way if some of our ideas don't pan out we can always discard them
easily.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
Doug Schaefer
<DSchaefer@xxxxxx
m> To
Sent by: "CDT General developers list."
cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>
clipse.org cc
Subject
21/07/2006 12:05 RE: [cdt-dev] Minutes Indexer Call
PM
Please respond to
"CDT General
developers list."
<cdt-dev@eclipse.
org>
O.K. Just sounds like your creating a lot of work for yourself that will
duplicate what the frameworks around the indexer already do. RCP apps
aren't
meant to be expensive (eRCP is a case in point).
The more difficult questions that you need to address are how do you get
the
index information to the development host in a timely fashion to satisfy
things like content assist? Where do you get the build information from?
How
do you handle resource deltas? Etc. It's a cool challenge and I hope you
succeed. Just don't break anything :).
Cheers,
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC member
http://cdtdoug.blogspot.com
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Chris Recoskie
Sent: Friday, July 21, 2006 11:56 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] Minutes Indexer Call
> What we previously had (cdtparser.jar) went to that extreme, I would
> prefer to identify optional dependencies and make the plugins work
> in both worlds well.
We are on the same page generally speaking, but I think if we are smart
about things we can do this without needing a whole RCP on the remote
system. APIs can have facades put over them for instance, so that the
parser can talk to both IResources and java.io.File. All of the Eclipse
plugin/extensions stuff can happen on the local client side, and it can
just tell the remote agent what settings to use.
A not so hypothetical example: say I have an extension point that lets me
provide a parser class to the indexer. Does the logic to read the
extension points to find out what parser class to use have to reside on the
remote side? No, I can do that on the client, and when I invoke the
indexer, just pass the name of the class to use, and the remote indexer JAR
can look for that class on its classpath. This way things are just as
flexible, without the RCP overhead on the remote system.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
John
Camelon/Ottawa/IB
M@IBMCA To
Sent by: "CDT General developers list."
cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>
clipse.org cc
Subject
21/07/2006 11:47 RE: [cdt-dev] Minutes Indexer Call
AM
Please respond to
"CDT General
developers list."
<cdt-dev@eclipse.
org>
But a "parser agent" can still be a set of plugins, no?
As long as the core/indexing plugins maintain some level of de-coupling
from the eclipse.core.resources, there shouldn't be a problem to run as an
RCP agent.
What we previously had (cdtparser.jar) went to that extreme, I would prefer
to identify optional dependencies and make the plugins work in both worlds
well.
--
JohnC
Chris Recoskie/Toronto/IBM@IBMCA
Sent by:
cdt-dev-bounces@xxxxxxxxxxx To
"CDT General developers
list."
07/21/2006 11:38 AM <cdt-dev@xxxxxxxxxxx>
cc
Please respond to Subject
"CDT General developers list." RE: [cdt-dev] Minutes
<cdt-dev@xxxxxxxxxxx> Indexer Call
Indexing via EFS is way too slow in the environments we are trying to
facilitate. In the EFS case, every single file that needs to be parsed has
to be transferred via some potentially slow communications channel just to
be parsed. If you can deploy a parsing agent on the remote host instead,
the traffic is minimized to a request to parse a set of files and the set
of results of parsing them. Generally speaking the latter is much more
bandwidth conservative.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
Doug Schaefer
<DSchaefer@xxxxxx
m> To
Sent by: "CDT General developers list."
cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>
clipse.org cc
Subject
21/07/2006 11:32 RE: [cdt-dev] Minutes Indexer Call
AM
Please respond to
"CDT General
developers list."
<cdt-dev@eclipse.
org>
I'm just going to pick on one item for now:
Enable remote indexing by decoupling the parser from the core as much as
possible. This way the indexer can be deployed as its own JAR file and
be run as an agent on the remote system. Part of this will involve as
well decoupling the indexer from any hard dependencies on having an
Eclipse project (although such information should of course be used if
available).
I understand the requirement is to deal with source code that resides only
on the remote system (mind you it has to be brought locally to edit.)
I don't understand how that requirement drives you to the solution of
extracting parts of the CDT into a separate jar file to be run outside the
context of the eclipse runtime and resources plugins. Going forward we need
to add more knowledge of the CModel to the parser frameworks to allow us to
take advantage of configurations as added by Mikhail S, and to deal with
the
Eclipse File System (EFS) that provide views on the file system for very
large projects.
For offline indexing proposed by Symbian, I can envision invoking the
indexer as a headless RCP application. Could we not do the same in your
environment?
Thanks,
Doug
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
