[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[2]: [equinox-dev] Updates on registry resolution
|
I like the 2 phase method. Just like to add that we probably need an
administrative facility that allows the user to override some of the
attributes of the packages. I.e. the author may have indicated a
compatibility with later versions, but in reality this is not true.
The user should have the possibility to override these settings,
especially the matching rules, imho.
Kind regards,
Peter Kriens
PR> Keith,
PR> I understand your motivation when you said that "no currently resolved
PR> plugins go unresolved" but I think this behaviour may not be desired by
PR> everybody. I think the algorithm must not try to be clever, because it
PR> will never satisfy all the cases.
PR> In order to avoid the "resolved / unresolved" by surprise, we are thinking
PR> of providing a way to do a "two phase install" :
PR> 1) you will install, uninstall etc... plugins and you will be able
PR> to query the system to know what are the results of these operations
PR> 2) once you are happy with the results you simply "commit" the
PR> operations you've done so they really take effect.
PR> Note that the first phase does not affect the running system.
PR> PaScaL
PR> Pascal Rapicault/Ottawa/IBM@IBMCA
PR> Sent by: equinox-dev-admin@xxxxxxxxxxx
PR> 05/28/2003 09:13 AM
PR> To: equinox-dev@xxxxxxxxxxx
PR> cc:
PR> Subject: [equinox-dev] Updates on registry resolution
PR> Hi,
PR> I'm moving this thread to the public knowledge.
PR> PaScaL
PR> ----- Forwarded by Pascal Rapicault/Ottawa/IBM on 05/28/2003 09:12 AM
PR> -----
PR> Keith Kimball@IRIS
PR> 05/27/2003 04:46 PM
PR> To: Rafael Chaves/Ottawa/IBM@IBMCA@IBMUS
PR> cc: Jeff McAffer/Ottawa/IBM@IBMCA, Pascal
PR> Rapicault/Ottawa/IBM@IBMCA
PR> Subject: Re: more updates on registry resolutionLink
PR> I'm impressed that you're making such good progress!!!
PR> I didn't understand your comment regarding changing back to original
PR> intent - do library plug-ins currently not get resolved if they have their
PR> prerequisites satisfied? Does this only happen when the library is not
PR> required by other plugins?
PR> I'm really looking forward to seeing your code.
PR> What have you do with the extension/extension point resolver?
PR> What are your thoughts regarding permitting/disallowing the
PR> enablement/disablement of plugins? We should discuss this with Jeff et al
PR> but my thoughts are that we should we refactor the resolver so that we can
PR> run it w/o effecting a running register (this is not too hard with the
PR> current resolver).
PR> Consider enable(plugin-list). My thoughts are that this should only be
PR> allowed if
PR> No currently resolved plugins go unresolved.
PR> Corresponding extension points of extensions implemented by this plugin
PR> must be able to handle dynamic plugins. For example, if the plugin
PR> provides a menu, the menu needs to get displayed.
PR> I'm not sure if there's an issue the other way - if a previously
PR> unresolved plugin provides an extension point, is it ok if there were
PR> dangling extensions?
PR> My thoughts are you run the resolver, see if a desirable end state if
PR> reached, and then carefully add the new plugins to the registry while
PR> keeping it consistent. This would take some refactoring but I believe it
PR> could be done.
PR> I believe disable has similar issues.
PR> I'm not sure this is inline with what Jeff and Pascal are thinking? Do you
PR> think we should talk later this week.
PR> Thanks for the update and great work!!
PR> Keith
PR> Rafael Chaves/Ottawa/IBM@IBMCA
PR> 05/26/2003 01:54 PM
PR> To
PR> Keith Kimball/Westford/IBM@Iris@IBMUS
PR> cc
PR> Jeff McAffer/Ottawa/IBM@IBMCA, Pascal Rapicault/Ottawa/IBM@IBMCA
PR> Subject
PR> more updates on registry resolution
PR> Hi Keith,
PR> Again, just to keep you updated with what is going on here...
PR> Here, we have made good progress. I have made the registry resolver to
PR> call the new dependency resolution algorithm instead of doing it itself,
PR> and so far I've been able to run the Eclipse registry resolution test
PR> cases with a low failure rate (8 in 189), due to known limitations in the
PR> new algorithm regarding conflict resolution and cycle detection. The good
PR> news is that some tests known to fail with the current implementation pass
PR> in the new one. The performance for running Eclipse is now equivalent to
PR> slightly better than the current implementation, and it has shown to scale
PR> well for huge registries. Also, for the incremental cases (addition,
PR> removal), the resolution time is proportional to the number of affected
PR> plug-ins, being really fast for small changes.
PR> I believe I am almost ready to help you in the whole registry resolution
PR> thing. I still need to implement handling cycles/conflicts in the way the
PR> current implementation does, and improving the delta generation. After
PR> that, it is just a matter of cleaning up the code and tidying up the
PR> object interfaces so it will be ready for going public.
PR> And what about you, are things going well? Please let me know if is there
PR> anything you need that I can help.
PR> P.S.: Jeff and Pascal may be asking how the number of test failures
PR> dropped from 57 to just 8... for now, I decided to change the version
PR> selection algorithm to be compatible with the current implementation (for
PR> library plug-ins, pick only the versions which are required by other
PR> plug-ins, or pick the highest version if none is required). So, now the 8
PR> failure cases are really problems that the previous implementation handled
PR> ok. Later, we may change it back to our original intent (resolve all
PR> library plug-ins that can have their pre-requisites satisfied).
PR> Regards,
PR> Rafael
--
Peter Kriens Tel. +46 30039800
Finnasandsvägen 22 Fax. +46 30039805
SE-43933 Onsala Mob. +46705950899
