| Re: [platform-update-dev] Role Based Updates |
Bob, yes, I would add the 'authentication' part too
a) authenticate user
either client or server authentication
b) associate user with policies (roles or whatever we want to call it)
install policy or acl server (like IBM policy director)
c) associate plugins with role
credentials for authentication from policy server
d) download/install/update
e) enable plugins
So it seems possible, now what would the use case be ?
a) user 'logs in the workbench' which shows roles that are enable ?
or
b) user attempts to enable role and we authenticate ?
I agree the 'log-in' is probably the best , so we need a client
authentication, like JAAS that would then connect to server ? This should
be done at startup right ?
(Embedded image moved to file: pic10360.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
Bob Foster
<bob@xxxxxxxxxx>
Sent by: To
platform-update-d platform-update-dev@xxxxxxxxxxx
ev-admin@eclipse. cc
org
Subject
Re: [platform-update-dev] Role
02/19/2005 04:11 Based Updates
PM
Please respond to
platform-update-d
ev@xxxxxxxxxxx
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
>
>
> ------------------------------------------------------------------------
>
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
Attachment:
pic10360.gif
Description: GIF image
