[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emfindex-dev] API Changes
|
Hi Jan,
On Wed, Oct 14, 2009 at 10:40, Jan Köhnlein <jan.koehnlein@xxxxxxxxx> wrote:
> Hi Knut,
>
> sorry, I didn't mean to spoil your usecase ;-)
>
No worries. Maybe it even isn't a valid use case. But let's have a look at that.
> It is important to have clear requirements for the eventing in order to
> discuss if it makes sense to have it inside EMF Index or on top of it. So as
> a client, could you elaborate on
>
> * What you are currently achieving with the events?
As in a typical Xtext DSL a lot of cross references end up being
resolved against the same IScope, we've implemented a cache in our EMF
Index based Xtext scope providers. The cache contains IScopes with
EObject proxies which have been created based on EObjectDescriptors
retrieved from the EMF Index. Note that for some of these
EObjectDescriptors there is no corresponding resource in the Eclipse
workspace.
We now also registered the scope provider as a listener to the EMF
Index events so that it can invalidate parts of its cache when
required.
> * What kind of events do you rely on (granularity, when fired, concurrency)?
The scope provider listens to any modification events (add, remove,
change). But to keep the implementation simple we only cared about the
resource granularity. That way any scope result in the cache
containing an EObject from the respective resource would be
invalidated.
For this use case we don't need any "pre" events, just "after the
fact" events. I.e. an event indicating that the EMF Index contents
*have* been changed.
I don't understand what your question about concurrency is about. Can
you elaborate on this?
> * Are there any scalability or performance issues to be taken into account?
In our use case the event listener is a very lightweight
implementation which quickly returns the control to the caller.
Regards,
--knut
