[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Role Based Updates
|
There are four parts to this, right?
a) Associating a list of allowed plugins with a role.
b) Associating a role with a user.
c) Downloading/installing missing/updated plugins for role.
d) Enabling role plugins and disabling all others.
Steps a and b can be done on the server. Steps c and d UM needs to do.
In other words, solution #2.
Bob Foster
Christophe Elek wrote:
Ok so do we work on 'dynamically installing plugins based on policy for a
specific user' or' allow runtime use of plugins based on role' ?
If this is install, I can see the following
1) Hook the start-up as Jeff mentioned to get User authentication
2) get user authorization/policy/ACL -> From a server ?
3) retrieve list of plugins and location
4) call UM to install plugins and enable them
or
1) Hook up startup to call UM server
2) server does authentication and authorization
3) UM installs list of feature that the server passes back
Any other solution ?
I like #2 as we leave the implementation to the User.
(Embedded image moved to file: pic17763.gif) Christophe Elek
IBM Software Group - Toronto Lab
Technical Team Lead - Cross product Tech Support
Cross components problem resolution specialist
Eclipse.org - Platform Core development
Phone: 905-413-3467 T/L: 969-3467 Toll Free: 1-800-IBM-SERV
Email: celek@xxxxxxxxxx
"James D Carroll"
<jamesdcarroll@ho
tmail.com> To
Sent by: "Eclipse Update"
platform-update-d <platform-update-dev@xxxxxxxxxxx>
ev-admin@eclipse. cc
org
Subject
[platform-update-dev] Role Based
02/19/2005 12:36 Updates
AM
Please respond to
platform-update-d
ev@xxxxxxxxxxx
Hey guys,
Sorry its been a while. Work's been a bear lately. Anyways....
In case you had forgotten the basic idea was that I wanted to see if there
is a way (and if not what can I do to make real) the following basic Use
Case:
1. User starts Eclipse
2. Eclipse presents user with login/password screen
3. Eclipse presents with user with only plugins that they need
I've done some more reading (what a concept, huh?) and I am almost
convinced
that it could be accomplished using the existing platform. Alot of the
pieces seem to be in place, especially after reading the parts in Help
called "Enable, disable, uninstall a feature", "Update policy", and
"Automatic update scheduler".
There were also lots of great questions that I'll summarize here so that we
can hopefully make this a reality.
1. What about the initial install?
Yes, there would have to be some kind of initial installation that takes
place, beyond the scope of this request. The absolute Eclipse core and
maybe
a config file of some kind that tells the Platform on startup that its in a
Role based installation/management environment and where to go to learn
more.
2. Do you cache plugins or download everytime?
I can't see a problem if there are plugins resident on a computer, as long
as the person who is currently logged in, can only access those features
that they are allowed. This is where the existing ability to disable
features can come in handy. The key would be to not allow someone to
activate a plug-in that they shouldn't.
3. Not all plugins can be dynamically loaded
Not my problem. As an optional feature targeted to business users it would
be their job to make sure that what's downloaded to their machines works.
Our job is only to enable automatic Role specific requests. The site
queried would be responsible for returning correctly.
4. What this about licensing?
License management is a side benefit of this request. By providing a
framework, others can create centralized management tools (or maybe we
could
create a reference implementation). For instance, a company might buy a
"global" license, a "site" license, or a set number of licenses. The
providing company could give the purchasing company a key that they enter
into the central server. How the server responds the request is up to them.
The key is to increase the granularity of the request from "anyone who
stops
by" to "who are you".
5. Does anyone really want this?
I think this hinges on two key factors: what is the current situation? and
what is the future of Eclipse?
The current situation is that there are companies out there who sell vastly
overpriced pieces of software whose sole purpose is to distribute software.
Think MS's SMS, Novell's Zenworks, or IBM's Workplace technologies. So
what's the difference between them and Eclipse? The ability to
differentiate between one user and another.
As for the future of Eclipse I see this as the only alternative. Its hard
to see now with so much work to be done, but eventually Eclipse will have
to
move from the Java hobbyist to the Java shop. And when that happens there
will be Managers. And they'll want to know this and control that and
because
they hold the purse strings nothing will enter their world unless they can
know this and control that. And when Eclipse becomes the de facto standard
for desktop integration (because somewhere somehow someone will say to
themselves "I'd like to create an Eclipse plugin, but does the world really
need another ANT plugin? How about an SMTP mail client?) it will only get
worse.
And at the bottom of the whole mess will be (should be) the most basic
question that only the Update component can answer:
Where do you want to go today?
James
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
------------------------------------------------------------------------
