[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Indexer conf call?
|
hi,
just to give one more opinion - Doug certainly
isn't alone in having concerns about this work. The showstoppers for me
were the potential collision with the new IIndex API, and the recombination
of results at a level above this API. From yesterday's conference call
it looks like we can avoid both of these, but this does leave other issues
open
* that the solution
cuts horizontally across the core
* this is particularly troublesome for a collaborative/distributed
project
* that the solution
(in terms of adapting each index client) is coming relatively late in CDT
4.0's release cycle
* (the high-level design has been available well
in advance)
* 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
* that no-one
has attempted this before (?), so the solution is in some ways experimental
These are points that naturally lead to asking "is
this worth the disruption?" - I think this is where Doug starts to
look at who in the community is calling for this feature, and who is likely
to benefit.
My feeling is that if more time was available to explore
how the proposed changes fit into the existing index clients, and how alternatives
compared, then we could come up something that changes less existing code.
Note that the completed work for enabling standalone parsing and indexing
would stand either way.
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?
thanks,
Andrew
cdt-dev-bounces@xxxxxxxxxxx wrote on 16/03/2007 17:50:14:
> Ok, I'm willing to be pleasantly surprised :-). Let's wait and see
> what the benchmarks show.
>
> Cheers,
>
> Greg
>
> p.s. Thanks for working your *ss off! We all appreciate the
> improvement it has made to CDT.
>
>
> On Mar 16, 2007, at 10:54 AM, Doug Schaefer wrote:
>
> > No, my objection is that I think there is a better solution that
> > minimizes
> > the impact on the rest of the CDT while still making your customers
> > happy.
> >
> > Instead of discussion the what if's, I really want to see the
> > benchmarks.
> > Having worked my *ss off to improve the performance of the indexer
by
> > ensuring each file is only parsed once, I think you'll be pleasantly
> > surprised by the performance using remote files, even with large
> > projects.
> >
> > And remember this is only done once, all things like call
> > hierarchy, content
> > assist, open decl, wouldn't need to parse remote files at all.
We
> > also have
> > a feature request to prebuild indexes as part of builds. If we
> > worked on
> > that instead, it would even be faster.
> >
> > But that is my opinion, and I don't have access to these
> > environments to
> > test, and I am easily swayed by facts.
> >
> > And all that being said, if this was truly only a remote indexing
> > solution,
> > I would be O.K. with it. We have the interfaces to support that.
My
> > real
> > problem is with putting the clients remote as well, especially
> > since these
> > will continue to evolve, likely by people who know little about
the
> > remote
> > story, and will be faced by this interface in the middle of the
code.
> >
> > Again, I am one voice and I will go with the flow if I feel I'm
the
> > only one
> > who feels this way. I do need to speak now to ensure that that
we
> > are truly
> > doing the right thing for all CDT users. There are lots of them
> > now, I'd say
> > almost a half a million, I want to make sure we aren't compromising
> > their
> > features either.
> >
> > And I think I've said all I have to. My ears and mind are open.
Let
> > wisdom
> > prevail :).
> >
> > Doug Schaefer, QNX Software Systems
> > Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
> >
> >
> >> -----Original Message-----
> >> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-
> >> bounces@xxxxxxxxxxx] On
> >> Behalf Of Greg Watson
> >> Sent: Friday, March 16, 2007 12:36 PM
> >> To: CDT General developers list.
> >> Subject: Re: [cdt-dev] Indexer conf call?
> >>
> >> Doug,
> >>
> >> Is your objection really that there will only be one client
of remote
> >> indexing (although PTP will likely use it also)? If this
is the case,
> >> then does that mean that only features that are used by many
> >> companies will ever be available in CDT? It seems a kind
of
> >> restrictive policy.
> >>
> >> I understand the reluctance to introduce more complexity
into CDT,
> >> but I think that the benchmarks will find that the performance
of
> >> indexing large projects via a remote filesystem will be abysmal.
File
> >> system operations tend to be very low level, and both the
indexing
> >> operation and accessing the index remotely will likely result
in a
> >> much larger amount of network traffic that simply accessing
a remote
> >> database. Since we're dealing with millions of lines of code,
I don't
> >> think this indexing model will be scalable.
> >>
> >> Cheers,
> >>
> >> Greg
> >>
> >> On Mar 15, 2007, at 2:44 PM, Doug Schaefer wrote:
> >>
> >>> I'm not totally sure what you guys are talking about.
If you are
> >>> talking
> >>> about the DAO thing, I don't consider that an API of
the CDT. In
> >>> fact I'd
> >>> rather people not know about it. It is a hack to allow
the IBM to
> >>> tear apart
> >>> the CDT at their whim while adding complexity to an already
too
> >>> complex
> >>> architecture. No one else will benefit from it. Did I
mention I
> >>> really don't
> >>> like this thing? ;) Until someone shows me the real costs,
I will
> >>> continue
> >>> to believe that indexing locally and accessing the files
over the
> >>> wire is
> >>> the correct architecture, especially now that the CDT
never
> >>> parses an
> >>> unchanged file more than once.
> >>>
> >>> So as such, the DAO interface can be changed whenever.
> >>>
> >>> Doug Schaefer, QNX Software Systems
> >>> Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
> >>>
> >>>> -----Original Message-----
> >>>> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-
> >>>> bounces@xxxxxxxxxxx] On
> >>>> Behalf Of Chris Recoskie
> >>>> Sent: Thursday, March 15, 2007 4:08 PM
> >>>> To: CDT General developers list.
> >>>> Subject: Re: [cdt-dev] Indexer conf call?
> >>>>
> >>>> Hi Andrew,
> >>>>
> >>>> I'm not sure if you mean whether we (IBM) have slack
in terms of
> >>>> our
> >>>> schedule for getting the items in before the freeze,
or if you mean
> >>>> whether
> >>>> we have slack as to what release of CDT they would
go in.
> >>>>
> >>>> I'll try to answer both questions.
> >>>>
> >>>> If (big if...) we were going to move all the clients
to the DAO
> >>>> model
> >>>> (call
> >>>> hierarchy, type hierarchy, search, etc.), our internal
schedule
> >>>> says we
> >>>> would be done this in early to mid April (I can break
this down in
> >>>> detail
> >>>> if anyone is interested). If the work only
has to make the
> >>>> feature freeze
> >>>> then there is a couple of weeks of slack. We
didn't get consensus
> >>>> yet
> >>>> that
> >>>> everyone has a warm fuzzy feeling about migrating
all the clients
> >>>> though.
> >>>> For those clients that have already a good separation
of UI and
> >>>> back end
> >>>> such as the call hierarchy and type hierarchy this
would be a
> >>>> relatively
> >>>> simple process, but for other clients it might or
might not take
> >>>> more work
> >>>> to factor out the back end. For our part we
are very concerned
> >>>> with
> >>>> making
> >>>> sure that quality is maintained and we've been rigorously
running
> >>>> the UI
> >>>> tests to make sure we haven't been breaking anything.
> >>>>
> >>>> In terms of CDT releases, that probably bears some
discussion and
> >>>> clarification...
> >>>>
> >>>> Markus was concerned about making it for API freeze...
I guess the
> >>>> questions we need to answer are what are our (as
in CDT's) APIs
> >>>> going to
> >>>> be
> >>>> and are we actually prepared to freeze them in two
weeks given that
> >>>> feature
> >>>> work is ongoing up until April 30th. Some things
are obviously
> >>>> going to
> >>>> be
> >>>> API (IIndex and the like, new project model stuff,
etc.) but in
> >>>> terms of
> >>>> the back end to the views and other index based services
it's not
> >>>> very
> >>>> clear to me what is going to be API and what isn't.
> >>>>
> >>>> What is API and what is not has a lot of ramifications...
> >>>>
> >>>> - What are we freezing for API freeze? Are
we in fact freezing at
> >>>> M6?
> >>>> Personally I'm not sure it's practical to freeze
API prior to
> >>>> feature work
> >>>> being done unless the system is very mature (i.e.,
if you are the
> >>>> Eclipse
> >>>> Platform and are not implementing a huge amount
of features in
> >>>> this
> >>>> release you have a much easier time of freezing API
ahead of your
> >>>> feature
> >>>> delivery than we do). That's just my $0.02
CDN though...
> >>>>
> >>>> - What can and cannot be put in between M6 and the
feature freeze?
> >>>>
> >>>> - What can and cannot be done in CDT 4.1 that doesn't
make it into
> >>>> CDT
> >>>> 4.0?
> >>>> In a 4.1 we can add new API but can't break existing
API. To break
> >>>> existing API we'd need a CDT 5.0, which would be
a year from now.
> >>>>
> >>>> In terms of our own desires at IBM, a year is a long
time to wait
> >>>> because
> >>>> it doesn't line up well with our product release
cycle (it already
> >>>> takes
> >>>> almost a year for us to deploy products based on
CDT, so it
> >>>> would be
> >>>> basically two years before anything consuming our
proposed
> >>>> functionality
> >>>> would see the light of day if we had to wait until
CDT 5.0 to
> >>>> get the
> >>>> changes in). It likely suits our purposes well
enough if we can
> >>>> get
> >>>> something done this year, and we are not entirely
picky about which
> >>>> release
> >>>> that would be so long as the changes happen and we
are not
> >>>> restricted by
> >>>> the versioning rules.
> >>>>
> >>>> What are people's thoughts on the API issues?
> >>>>
> >>>> ===========================
> >>>>
> >>>> Chris Recoskie
> >>>> Team Lead, IBM CDT Team
> >>>> IBM Toronto
> >>>> http://www.eclipse.org/cdt
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> From: Andrew.Ferguson@xxxxxxxxxxx
> >>>>
> >>>> To: "CDT General developers
list." <cdt-dev@xxxxxxxxxxx>
> >>>>
> >>>> Date: 15/03/2007 03:06 PM
> >>>>
> >>>> Subject Re: [cdt-dev] Indexer conf call?
> >>>> :
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> hi,
> >>>>
> >>>> I've posted minutes for the meeting here:
> >>>> http://wiki.eclipse.org/index.php/CDT/calls/
> >>>> IndexingMar2007_1
> >>>> if I've missed anything then please add it in.
> >>>>
> >>>> We ran out of time at the end, just as we were discussing
the
> >>>> scale of
> >>>> changes proposed. My next
> >>>> question was going to be if you have any slack in
terms of whether
> >>>> these
> >>>> changes make CDT 4.0?
> >>>>
> >>>> thanks,
> >>>> Andrew
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> *******************************************************************
> >>>> **
> >>>> *
> >>>> Symbian Software Ltd is a company registered in England
and Wales
> >>>> with
> >>>> registered number 4190020 and registered office at
2-6 Boundary
> >>>> Row,
> >>>> Southwark, London, SE1 8HP, UK. This message is intended
only for
> >>>> use by
> >>>> the named addressee and may contain privileged and/or
confidential
> >>>> information. If you are not the named addressee you
should not
> >>>> disseminate,
> >>>> copy or take any action in reliance on it. If you
have received
> >>>> this
> >>>> message in error please notify postmaster@xxxxxxxxxxx
and delete
> >>>> the
> >>>> message and any attachments accompanying it immediately.
Neither
> >>>> Symbian
> >>>> nor any of its Affiliates accepts liability for any
corruption,
> >>>> interception, amendment, tampering or viruses occurring
to this
> >>>> message in
> >>>> transit or for any message sent by its employees
which is not in
> >>>> compliance
> >>>> with Symbian corporate policy.
> >>>> *******************************************************************
> >>>> **
> >>>> *
> >>>> _______________________________________________
> >>>> 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
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
********************************************************************** Symbian Software Ltd is a company registered in England and Wales with registered number 4190020 and registered office at 2-6 Boundary Row, Southwark, London, SE1 8HP, UK. This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster@xxxxxxxxxxx and delete the message and any attachments accompanying it immediately. Neither Symbian nor any of its Affiliates accepts liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy. **********************************************************************
