Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Introducing the PDOM
It's not so terrible as it seems to be if you take in account, that for PDOM purpose you barely need most of the features that any relational data base must implement (SQL API, transactions, concurrent access, security issues etc.). 

Recoskie, Chris wrote:


Write your own eh?  I smell a technology sub-project ;-)

___________________________________________

Chris Recoskie
Software Designer
Texas Instruments, Toronto
http://eclipse.org/cdt




-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]

On

Behalf Of Doug Schaefer
Sent: Thursday, September 29, 2005 11:17 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] Introducing the PDOM

That's my understanding as well (and I am similarly qualified :). I

will

take this through the Eclipse legal guys but my understanding is that

a

couple of other projects are already using Derby (BIRT I think is

one).

One thing I will do is make sure we can substitute the database engine
so that people taking the CDT and having licensing issues can

substitute

a different engine, or have no engine at all in which case you would
default to the current behavior.

Actually, we need this anyway in case it turns out that we can't get

the

performance near what we'd need with Derby or SQL. Ideally, I would
write my own database engine that is customized to our requirements,
however, that's a lot of work...

Thanks,
Doug

On Thu, 2005-09-29 at 10:40 -0400, Recoskie, Chris wrote:

As far as I know, the Apache and EPL licenses are compatible (vis a
vis
Xerces), but IANAL, so do your due dilligence.

___________________________________________

Chris Recoskie
Software Designer
Texas Instruments, Toronto
http://eclipse.org/cdt




-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx

[mailto:cdt-dev-bounces@xxxxxxxxxxx]
On

Behalf Of Treggiari, Leo
Sent: Thursday, September 29, 2005 10:37 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] Introducing the PDOM

Hi Doug,


       Absolutely. I'm currently looking at Derby, an Apache

embedded

       SQL database that has shown some good performance.

Would there any "different" licensing issues with shipping "Derby"

with

a product that ships CDT?

Thanks,
Leo

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx

[mailto:cdt-dev-bounces@xxxxxxxxxxx]

On Behalf Of Doug Schaefer
Sent: Thursday, September 29, 2005 9:45 AM
To: CDT General developers list.; Sumit Sarkar
Subject: Re: [cdt-dev] Introducing the PDOM

Hi Sumit,

This is definitely something else to consider. I know some at IBM

have

this requirement as well where the source files reside on a remote
machine. One option was to have the indexer run remotely. With the

PDOM,

this should be possible and would provide functionality for all

parser

based features (not just the index based ones). Since I'm using

SQL

for

queries, we should be able to easily handle that on the local

side.

We

would need to figure out how to package up the remote agent,

though.

I'll make sure I document this as a requirement.

Thanks,
Doug

On Thu, 2005-09-29 at 00:31 -0400, Sumit Sarkar wrote:

Hi Doug,

In our HP Remote Development product, we are facing the problem,

that

"indexer" is reading the local header files (if they exist) to

build

the DOM. In your new architecture, if you consider a way to map

the

local header files with the remote (or from other location),

that

will

be great. That way, it will be easier for us to use the remote

header

files to index the remote project. I am not sure whether CDT 3.0

has

already this feature or not.

Thanks,
sumit

On 9/28/05, dschaefer@xxxxxxx <dschaefer@xxxxxxx> wrote:


       Absolutely. I'm currently looking at Derby, an Apache

embedded

       SQL database
       that has shown some good performance. I'm still learning

SQL

       but I think you
       can merge tables together quickly. So you could create a

PDOM

       in one
       project, one containing all your header files for

example,
and

       package it up
       for delivery, and auto-merge it into the PDOM for users'
       projects.

       I'll record it as a requirement and we'll definitely

give

that

       a try as this
       thing matures over the upcoming weeks.

       Cheers,
       Doug

       "Treggiari, Leo" <leo.treggiari@xxxxxxxxx> said:
       > Hi Doug,
       >
       > I think it is a GOOD idea.  If we have CDT-wide

tool-chain

       definitions,
       > then maybe the tool-chain could provide a pre-built

PDOM
for

       its own
       > header files.  So, you might want to consider being

able
to

       handle
       > multiple PDOMs for a single project.
       >
       > Regards,
       > Leo
       >
       >
       > -----Original Message-----
       > From: cdt-dev-bounces@xxxxxxxxxxx
       [mailto:cdt-dev-bounces@xxxxxxxxxxx]
       > On Behalf Of Doug Schaefer
       > Sent: Wednesday, September 28, 2005 5:06 PM
       > To: cdt-dev@xxxxxxxxxxx
       > Subject: [cdt-dev] Introducing the PDOM
       >
       > Hey gang,
       >
       > As the next step in the evolution of the CDT DOM, I am
       starting work on
       > a persistence strategy that will allow us to greatly

reduce

       the amount
       > of parsing we do in both the indexer as well as the

features

       that use
       > the DOM (content assist, open decl/def, etc). The idea

is
to

       stow away
       > names and bindings from the DOM into a database to

allow
for

       binding
       > resolution and decl/ref searches to get information

from

       this database
       > instead of having to reparse. I am calling this

database
the

       PDOM, or
       > Persisted DOM.
       >
       > The premise is that database look-ups will be faster

than

       building the
       > AST for header files over and over again. That should
       finally solve our
       > indexer performance problems. And if not, I am making

it
so

       that we can
       > simply toss away the whole thing and take another tact
       without
       > disturbing the status-quo.
       >
       > I am producing a slide package on all this that I will
       present at the
       > CDT developer conference next month. In the meantime,

you

       will notice
       > code going into the CVS repository as I start trying

out

       these ideas in
       > optional plugins: org.eclipse.cdt.pdom.core and
       org.eclipse.cdt.pdom.ui .
       >
       > If you have any questions, opinions, or even better -

would

       like to help
       > out, please let me know. I am certainly open to

opinions

       that make me
       > think this is a bad idea and save me all this work :)
       >
       > Cheers,
       > 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

_______________________________________________
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

Back to the top