Bug 336186

Comment 1 Susan McCourt 2011-02-03 11:07:44 EST

I've been meaning to ask about the relationship between "services" and "extension points."  Is there one?  I tend to think of services in the OSGi way, where you typically want one implementor, the "highest ranking" one.  But I guess no reason not to iterate through all implementations and use them all.  Is that what we mean when we say extension points?

Comment 2 John Arthorne 2011-02-03 11:58:51 EST

Extension points means the places in our code where we allow an alternate service to be plugged in. It really means the areas in our code that we open up to others to insert/customize behaviour. The way clients hook into those points is via plugins that declare services.

Extension points are essentially just documentation: it has an id, and declares what kind of function it expects (parameters, return value).

Comment 3 Susan McCourt 2011-02-07 12:29:24 EST

Is it fair to say that in Orion we are implementing the extension points using services/service registry.  For example, "editorAction" is a service lookup.  This is different than the desktop where we had an extension registry and an OSGi service model which were not related.  (I know this discussion has been had tons of times before in Eclipse, I'm just trying to clarify our strategy for Orion).

Comment 4 Simon Kaegi 2011-02-07 13:20:13 EST

(In reply to comment #3)
> Is it fair to say that in Orion we are implementing the extension points using
> services/service registry.

That's the idea for now. The plugin metadata is all cached similar to the desktop extension registry so the services that get registered by plugins are lazy in terms of plugin activation. I'd like to see how far we can take this approach as I think it's likely sufficient and avoids all those awkward service vs. extension conversations.

Comment 5 Simon Kaegi 2011-02-07 13:22:33 EST

Just want to add that the editorAction is actually doing the wrong thing in terms of allowing for lazy activation. Ideally the current "info" method should be something in the services properties so we can render the action in the editor without having to create the iframe etc.

Comment 6 Boris Bokowski 2011-02-07 13:26:57 EST

(In reply to comment #5)
> Just want to add that the editorAction is actually doing the wrong thing in
> terms of allowing for lazy activation. Ideally the current "info" method should
> be something in the services properties so we can render the action in the
> editor without having to create the iframe etc.

yes!

Comment 7 John Arthorne 2011-04-27 17:36:53 EDT

This was done for M6.