[news.eclipse.technology.equinox] Re: Separating concerns (part II)

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

"Olivier Gruber" <ogruber@xxxxxxxxxx> wrote in message
news:b623ui$65c$1@xxxxxxxxxxxxxxxx
> For disabled... I didn't know we had a disabled state...
> so what is the difference between disabled and unloaded ?

No such thing as unloaded.  deactivated, disabled, uninstalled.
deactivated = no classloader but still in the registry.  Could be activated
via normal mechanism
disabled = deactivated + can NOT be reactivated.  Extensions retracted.
Effectively uninstalled but still there
uninstalled = disabled + removed from disk/configuratoin.  Eclipse does not
know about it.

> While I am on the subject, I also don't quite understand
> the primed state... Does it mean that the class loader
> is present but the plugin has not executed any code yet?
> If so, this is very analog to the OSGi RESOLVED versus
> ACTIVE states for a bundle (remember a bundle is equivalent
> to a library plugin).

That's the point.  Resolved seems like an interesting state.  Eclipse may do
well to have such a thing.

Note that the "primed" state is just an idea.  I would not focus too heavily
on that yet.

> I am questioning that the delta should include extension
> information... I don't have a strong opinion either way...
> but I would like to hear the rationale if we have two
> levels of notification, one for extension-related events
> and one for plugin life-cycle events.
>
> For simplicity, wouldn't it be more interesting to separate
> again. Have events for plugin life-cycle and administrative
> extension-related events...
>
> I can hear already the clamor about too many events...
> I disagree in advance... :-)
>
> We have the events to extension providers.
> We have the events to extension providers.
> Those are key and all plugins will receive them.
> For backward compatibility, they may ignore them...
> for an optimization, we may send them to only plugins
> declaring themselves dynamic-aware...
>
> Then, we are likely to have only one administrative plugin,
> the update manager today...
> It will listen to plugin events and all extension-related
> events, if and only if it has an interest in those...
> Today, it is not obvious to me that the update manager
> will even care about extension-related events...
>
> In general, plugins needing to know about plugin life-cycle
> events AND extension-related events should be pretty rare...

The key point to me is that extensions and extension points are tied to
plugins. You cannot have the former without the latter.  Plugins (and thus
extensions and extension points) are managed in a plugin registry.  The
deltas we are talking about are plugin registry deltas.  Adding an extension
is a change to the registry.  There are other ways in which the registry can
change.  The delta mechanism captures these various possibilities in a
relatively simple and consistent way.

Jeff