Re: [platform-update-dev] Where to start/ How to help

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

platform-update-dev-admin@xxxxxxxxxxx wrote on 02/11/2005
11:18:48 PM:

> *>--From: Jeff McAffer --<*
> 
> The tricks in this are that:
> a) you need SWT if you are going to draw a login dialog
> *hmmm... hadn't thought about that. But in Ed Burnette's RCP article
he
> defines an absolute minimal RCP installation. Now, please correct
me if I am
> wrong, but isn't Eclipse just an RCP app that tends to load development
> based plugins? And it doesn't care what kind of plugins that it loads
as
> long as they all play by the same rules. From what I've read there
is
> currently an initiative to ease distributution of Eclipse; to make
the
> initial client side as small as possible. We can piggy back that.

Yes but the context of that comment was bootstrapping.
 At the point you want to prompt the user to login and thus determine
what plugins they should have, you have yet to determine the configuration.
 Without a configuration you have, by default, no plugins.  So
the question, where do you get the SWT plugin?  You can get around
this by declaring some set of plugins as primitives and handling them specially.
 My point was that you have to do this explicitly.  No free lunch.

> b) what do you do if the user changes on next
login (e.g., do you uninstall
> plugins not in that user's list)
> *My initial thought is to delete the unused plugins so that every
time that
> a different user logs into a station the plugins match their role.
 If there
> are common plugins then new ones would only be dowloaded if there
was a
> newer version. The response from the the update "site" would
determine that.
> 
> c) do you cache or do you install the plugins every time
> *Per above my intial gut feeling (until it can be based on actually
getting
> into the code) is too delete them.  But maybe it could be handled
by a well
> written config.ini?  The goal is too insure that each person
gets the tools
> that they need,but nothing more.

Deleting is a bummer if you think that users switch
alot and download may take time.  If either of these is false then
it may be ok.  The other optoin is to simply ensure that only the
right ones are presented to the runtime.  This is the role of th platform.xml
if you are using update.configurator or config.ini if you are not (or some
other file if you are using a different configurator).  

> d) what do you do about restart (do you need
to restart after the install)
> *This is where I expect that OSGI really steps up and proves itself,
since
> Eclipse has already started any new or updated plugins must be discovered
at
> runtime without a restart. If OSGI/Eclipse can't handle dynamically
added
> plugins, frankly, we might want to ask what OSGI adds to the party.

OSGi is plumbing.  It allows you to add and remove
plugins on the fly.  Building a dynamic system is a cooperative effort.
 The air traffic control analogy pops into my head.  The system
works fine if the pilots listen to the commands and take the appropriate
actions.  So for example, if you install a plugin that extends some
extension point but the guy providing the extension point doesn't listen
for new plugins, you'll be in a restart scenario.

> "Do the following,:  "
> *Sweet. Something to do. I'll work on it. Sometimes (usually when
its
> something new) having a concrete list of tasks to learn from is critical.

Don't get too excited.  That was pretty much
off the top of my head.  We've had some discussions around here on
this topic but as yet no actual code released etc.  As I said before,
we like the scenario but as yet are not promising anything.

Jeff