Re: finding all Java classes in a project

> That only works, when you have questions for the "other details" 
> coming at lower rates. Computing rarely needed stuff

Well, a related question to ask is how much of the computed detail will 
be used. If only a small piece of data
is used at higher rates, then it evens out. I believe that will be a 
typical case. I don't think MDR will be heavily
bombarded with requests for complicated things.

> on-the-fly is a well-known practise. Once computed data can be cached 
> and pessimistically thrown away as changes are detected.
>
> However each such optimization either complicates the model 
> implementation (if it is to be transparent, which is IMHO a 
> requirement in order to support MDA clients), or requires special 
> helper to populate the model. In regards of Java/MDR

Actually, it is the other way round. I am proposing not to cache 
anything that can be quickly computed. That makes life
simpler because there is no need to synchronize with anything.

More specifically for the Java/MDR integration: In my previous job, we 
discussesd this issue a lot and decided to
keep the cache really lightweight so creation and updation are fast and 
easy.  Obviously, that works only if you
have a fast Java analysis engine (like javac).

> integration I think these issues were among the reasons your approach 
> was not immediatelly applied after evaluation - it may not fit our 
> purposes.

I am not convinced it doesn't. You are assuming that the MDA clients 
want instantaneous return of data from MDR.
If you can allow a few seconds for those things, then it becomes easier 
to deal with.

>
> I believe it should be an implementation detail of the model content 
> provider how often or at which point if fills the model with real 
> data, provided that it is available at the return to the calling client.

Yes. We are discussing implementation here! :-)

Sreeni.