[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Indexer conf call?
|
Hi Andrew and Markus,
First, let me apologize for the delay in this response. I wanted to wait
until I got indexing numbers from Chris before I sent this out.
Thanks very much for your feedback. We understand the concerns the
community has with the feature we are trying to deliver. Due to the
concerns of the community, we realize this work will most likely not make
it into CDT 4.0. Despite that, we still believe this is the best solution
to the remote development problem. We still would like to continue this
discussion so that the design can improve and evolve in time for a future
release of CDT.
> Andrew:
> * that the solution cuts horizontally across the core
> * this is particularly troublesome for a
> collaborative/distributed project
<snip>
> * that no-one has attempted this before (?), so the solution
> is in some ways experimental
The general approach of this solution is decoupling the UI components from
the low-level data model (IBindings and IASTNodes) by using the high-level
data model (ICElements) as a transfer medium. In this way, the
architecture itself is not experimental since it is a variant of the
Model-View-Controller paradigm.
> What about the possibility of committing and continuing the
> prototyping work on a parallel branch of CDT HEAD, so that we can
> see how the dao pattern applies to the remaining index clients? We'd
> then buy more time for discussion, and a better basis to form opinions
on?
We are open to moving this work onto a parallel branch of CDT HEAD. That
would certainly make it easier for the community to see what sorts of
changes are involved in our proposal.
> Andrew:
> * as it is undecided if the index client remote service
> implementations would be open-sourced, there may be no benefit to
> the CDT community from the work
> Markus:
> * While giving the impression of bringing a remote solution to CDT
> its really about opening CDT for custom implementations of various
> features. While this creates potential problems, it does not add
> value to CDT.
Originally we were not sure whether a full remote implementation was within
the scope of the CDT project. However, we are certainly willing to provide
an open source remote implementation for the community.
> Markus:
> * For an open-source solution of remote-developement I'd not follow
> IBM's approach. I prefer Andrew's proposal (integrate a remote
> index via IIndexFragment) or Doug's proposal (using EFS).
We have explored both of these alternatives thoroughly last Fall. We have
two main concerns with integrating a remote IIndexFragment:
1. Expensive in terms of number of round trip connections: A client can
invoke methods on IIndexBindings and IIndexNames retrieved from a remote
fragment. In most cases, this means a remote IIndexBinding/IIndexName
would need to be able to connect back to the remote host at any time. Take
the call hierarchy, for example; IIndex.findDefinitions() performs the
main search which returns an array of IIndexNames. For each of the X
names, resolveBinding() is called. The resulting IIndexBinding is
inspected to see if it's applicable to the original query. This means a
minimum of X + 1 round trip connections between the client and the remote
host. It would be more optimal if that filtering could be performed on the
remote host so that only the relevant bindings would be sent back to the
client.
2. Locking: We cannot reliably enforce locks acquired by the client
because of potential network interruptions.
Using EFS entails transferring every single file necessary for a reindex
over the network. There are a number of common operations that can trigger
a full reindex:
* Switching between different build configurations.
* Adding/removing include paths.
There are also operations where manually triggering a full reindex is
necessary for many index-based features to be accurate:
* Changing or adding macros.
* Changing a header file that is referenced by many source files.
The Firefox code base contains approximately 155 MB of source.
Transferring that amount of data over 100 kilobyte/sec link takes just over
25 minutes. Having to wait 25 minutes on top of however long it takes to
index every time a user switches between debug/release configurations or
changing macros or headers is not practical for anyone.
Furthermore, the numbers Chris' recently posted to the list suggest that
indexing over SMB is 4 times slower than indexing locally. So a 7 minute
indexing of Firefox locally would take just under half an hour remotely.
> Markus:
> * We must carefully design on how feature-implementation can be
> exchanged in CDT. How do we handle the case where different
> plugins want to exchange a feature-implementation? That sounds
> trivial, nevertheless the proposed mechanism can be used for
> vendor-specific feature-extensions or 'bug-fixes' that did not
> make it into CDT.
We have opened bugs 177658 (framework-level) and 177761 (call
hierarchy-specific) to discuss alternatives and concerns with feature
exchange.
> Markus:
> * Opening up CDT in such a way creates an API that limits the
> possibilities of what CDT can do in a binary compatible manner
> in the future. Therefore these APIs need careful discussion per
> feature that is supposed to be opened. Up to now there is only
> a huge patch that is not suitable for leading such a discussion.
> (the patch contains too many different things and does not apply
> for large parts). I am worried that under pressure we add some-
> thing we did not carefully think about.
Going forward, we will be posting separate patches for the framework, and
the various features we plan to migrate. As mentioned above, we have
opened bug 177658 for the framework patch, and 177761 for the call
hierarchy patch. We will open separate bugs to discuss other features,
such as type hierarchy and code navigation (i.e. find references,
definitions, declarations) in the future.
> Markus:
> * Most of the features that you want to open (which ones excatly??)
> have been either developed or at least been maintained by WindRiver
> during the 4.0 release cycle. Making late changes on top of what
> we have done conflicts with our primary goal of having a stable
> 4.0 release. In other words, we have made the new stuff available
> in M4 and M5 such that the community can detect the remaining bugs.
We don't want to destabilize CDT either which is why we haven't committed
anything related to the architectural changes we have been proposing. We
value the contributions that Wind River, Symbian, QNX, Intel and all the
other organizations have made over the years and we are hoping to continue
these discussions so we can find a remote development solution that works
for the entire CDT community.
Jason Montojo
IBM CDT Team
IBM Toronto Lab
905-413-5228
jmontojo@xxxxxxxxxx
