Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-core-dev] Conditional Plugin Loading

You will still likely face some bootstrapping issues if you want to 
download the inclusion/exclusion filters dynamically, as these are 
specified using the regular extension point mechanism.
You would need to ensure that the plugin(s) contributing these extensions 
are known in the platform registry before the Workbench is activated.

Nick




Philip Borlin <pborlin@xxxxxxxxxxx> 
Sent by: platform-core-dev-admin@xxxxxxxxxxx
12/02/2003 12:05 PM
Please respond to
platform-core-dev


To
platform-core-dev@xxxxxxxxxxx
cc

Subject
Re: [platform-core-dev] Conditional Plugin Loading






This looks pretty compelling.  This would really simplify things so I 
wouldn't have to worry about loading/unloading plugins.  I could simply 
download a users inclusion/exclusion filters (preset up by an admin 
tool) at login time and then the UI would apply the filters so it only 
showed relevant information.  I like it.

Thanks,
-Phil


Nick Edgar wrote:
> You may also be interested in taking a look at the support for filtering 

> by activity or role in the UI.
> A summary of this support (a little bit out of date, but still describes 

> the overall approach accurately) is available from the UI team's 
proposals 
> page:
> 
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/docs.html

> 
> Click on Roles Support.
> 
> Nick
> 
> 
> 
> 
> 
> Philip Borlin <pborlin@xxxxxxxxxxx> 
> Sent by: platform-core-dev-admin@xxxxxxxxxxx
> 12/01/2003 03:38 PM
> Please respond to
> platform-core-dev
> 
> 
> To
> platform-core-dev@xxxxxxxxxxx
> cc
> 
> Subject
> Re: [platform-core-dev] Conditional Plugin Loading
> 
> 
> 
> 
> 
> 
> OK the full story:
> 
> We are writing a custom app on top of the Eclipse Platform for a 
> controlled group of users (contracted content providers).  We provided 
> our own IPlatformRunnable and are using our own custom UI extension 
> points so we can have more control over the workflow and user 
> experience.  We don't have to worry about anyone installing plugins 
> since we didn't implement a UI to the update manager.
> 
> The use case:
> 
> Basically there are many different types of content that these authors 
> can create and we currently have separate tools for each type of 
> content.  We want to integrate all of the current tools into one tool 
> and want to give the whole stack to each author.  In order to submit 
> content the author needs to be on contract (for IP/legal issues and also 

> to get their royalty checks) so we don't want authors using parts of the 

> tool which will generate content they aren't contracted for.
> 
> This gets back to logging in.  When they log in I only want to load the 
> plugins that handle the content they are contracted for.  More 
> specifically some plugins need to load on launch such as the plugin with 

> the IPlatformRunnable and any ui/security code needed to display the 
> login prompt.  After login other plugins may or may not need to be 
> loaded based on the type of contract the user is on.
> 
> I guess I was thinking originally that I would tell Eclipse (OSGi or 
> whatever) to never load certain plugins and then the built in plugin 
> loader would load everything else.  Should I take over plugin loading to 

> make sure plugins I don't want to be loaded don't get loaded instead? 
> Or some other alternative?
> 
> Hope this explains the problem well enough and thanks for your time,
> -Phil
> 
> 
> 
> Jeff McAffer wrote:
> 
>>The new runtime exposes the capability to dynamically install plugins. 
>> The rest of eclipse has not yet been updated to discover/use these 
>>newly installed plugins however.  The ability to block installation was 
>>not really on the plan.  I think the sort of scenario you describe was 
>>more in the order of user-based configuration discovery.
>>
>>Having said that, the new runtime does have a security model which, if 
>>you turn it on, allows for the blocking of admin calls such as install. 
>> The other approach that is supported is the ability to run without an 
>>agent that knows how to install bundles.  That is, you can configure and 

> 
> 
>>eclipse install with no update/install.  Given that you know/trust the 
>>set of plugins you start with, you can successfully prevent the 
>>installation of any plugins which would call the install API.  A sort of 

> 
> 
>>weak bootstrapping security.
>>
>>I would be interested in more on your usecases.
>>
>>Jeff
>>
>>
>>
>>*Philip Borlin <pborlin@xxxxxxxxxxx>*
>>Sent by: platform-core-dev-admin@xxxxxxxxxxx
>>
>>12/01/2003 12:25 PM
>>Please respond to
>>platform-core-dev
>>
>>
>>
>>To
>>               platform-core-dev@xxxxxxxxxxx
>>cc
>>
>>Subject
>>               [platform-core-dev] Conditional Plugin Loading
>>
>>
>>
>>
>>
>>
>>
>>
>>When the buzz around the rich client platform first started to appear I
>>remember a the talk of the possibility of conditionally loading plugins.
>> For example:
>>
>>A user logins in and is presented with only the plugins her credentials
>>authorize her to access.
>>
>>I am not worried about the authorization service so much as the ability
>>to block plugins from loading.  Is this coming?  If so does someone need
>>help?
>>
>>Thanks,
>>-Phil
>>
>>_______________________________________________
>>platform-core-dev mailing list
>>platform-core-dev@xxxxxxxxxxx
>>http://dev.eclipse.org/mailman/listinfo/platform-core-dev
>>
> 
> 
> 
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-core-dev
> 
> 
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-core-dev
> 
> 


_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev




Back to the top