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

["James D Carroll" <jamesdcarroll@xxxxxxxxxxx>]

Thanks to both of y'all. I subscribed to the mailing list a while ago, but
there was precious little traffic.  It's awesome that once a newbie ventured
into your world that there's plenty of folks who are ready to help and guide
folks like me.

*>--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.

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.

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.

"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.

Jeff
______________________
From: Christophe Elek

James,
Welcome to the fantastic world of eclipse update :)

*Thanks!!

You are not the only one who wants this feature. They way we designed it
(which may be review) is to have the authentication/list of plugin at the
server level
I believe I created (long time ago) a secure servlet that would return a
modified site.xml which would only list available features for this user

* Nice to know that I'm not alone. I would be very interested in that work,
but I would be more interested in allowing this service in Eclipse as
opposed to providing that service. Frankly, I think if we can do this (and
sell Eclipse as a viable development and business framework) we can create
an entire market for app distribution and liscencing that rivals MS's MSS
and Novel's ZenWorks. Or even we dare IBM'a own Workplace technologies.

Now, what exact scenario do you want to achieve ?

* Role: SysAdmin
    - Recieves directive from insane business managers to install Eclipse
based application suite.
    - Accountible for liscensing restraints;
    - Must limit functionality based on role due to Complinace and other
constraints; the right people get the right tools
    - Add, delete, move user functions handled centally

* Role: User
    - Starts Eclipse based application
    - Application asks for UserId and Password
    - Framework queries URL for list of plugins to distribute
    - Code dowloaded
    - User is presented with only those tools (plugins) that are needed for
their job.

* Role: Developer
    - Writes functional component that enable users to get the job done
    - Focus on component, leaves consolidation to others

I hope that clarifies the vision that I have for this part of Eclipse.
Probably not. But HEY! at least we're talking about it!


James