[news.eclipse.tools] Re: workspace startup event

["Jeff McAffer" <jeff_mcaffer@xxxxxxx>]

Eric,

We certainly did not set out to "preclude an entire class of potential
plugins".  We are in the enabling game.

I must have missed the posts where you detailed the class of plugins you are
talking about.  Randy's action enablement case aside, I'm having trouble
coming up with use cases that *require* plugin activation to be triggered by
installation.  I can see lots of people, as discussed, *wanting* their
plugin to get activated on startup but you seem to be indicating something
more fundamental.  Perhaps there are use cases we have missed?  Could I
bother you to provide some concrete details?

Jeff

"Eric Clayberg" <clayberg@xxxxxxxxxxxxxxxxxx> wrote in message
news:9nha8a$oao$1@xxxxxxxxxxxxxxxx
> "Jeff McAffer" <jeff_mcaffer@xxxxxxx> wrote in message
> news:9ngpfo$ioa$1@xxxxxxxxxxxxxxxx
> >
> > - Pure startup time is not the whole story.  It has been suggested that
> long
> > startup sequences should be forked into low-priority tasks.  A common
use
> of
> > this feature would be to ensure that their plugin's initialization is
done
> > before their plugin is actually needed.
>
> That is one reason...but hardly the only reason.
>
> > Forking reduces the apparent
> > startup time of the platform but eats subsequent CPU, disk IO and memory
> > resources.  Good idea unless you have many such plugins but are actually
> > only wanting/needing a subset during any particular session.
>
> But what if you have a plug-in, that by its very nature, *will* be used in
> *every* session?
>
> > - Running code at startup requires that the plugin be activated.
>
> Which is exactly what we need to/must do.
>
> > - Loading the first class from a plugin is the trigger for plugin
> > activation.  Plugin activation tells the plugin it is actually needed.
>
> What if you have a plugin that is "needed" based upon the very fact that
it
> has been installed?
>
> > - An overriding design goal for Eclipse is it that it scale well into
the
> > hundreds of installed plugins from a multitude of vendors or product
> > families.
>
> While eliminating entire classes of potential plugins?
>
> > - The fact that several people want this feature indicates that there
will
> > be several plugins doing startup code.
>
> The fact that several people want it, and you folks don't provide an
> "official" solution means that a variety of (potentially conflicting)
> hacks/cheats will be required.
>
> > - In the current implementation all of the plugins with open views are
> > activated as a byproduct of creating the views.
>
> And what do you do if you have a plugin that does *not* have any views and
> yet must be active at all times? Is the IBM world view of what can be a
> plugin so limited as to preclude an entire class of potential plugins?
>
> > This means that the users
> > "working set" of plugins is activated on restart.
>
> OK, so how can you add to that "working set" without requiring an open
view?
>
> > If the user was not using
> > the plugin previously, it is not activated.
>
> And if they were using the plugin, but that plugin does not manifest
itself
> in a view, then what?
>
> -Eric
>
>