Re: [equinox-dev] Updates on registry resolution

["Pascal Rapicault" <Pascal_Rapicault@xxxxxxxxxx>]

Keith, 

I understand your motivation when you said that "no currently resolved plugins go unresolved" but I think this behaviour may not be desired by everybody. I think the algorithm must not try to be clever, because it will never satisfy all the cases.

In order to avoid the "resolved / unresolved" by surprise, we are thinking of providing a way to do a "two phase install" : 
        1) you will install, uninstall etc... plugins and you will be able to query the system to know what are the results of these operations
        2) once you are happy with the results you simply "commit" the operations you've done so they really take effect.

Note that the first phase does not affect the running system.

        PaScaL

Pascal Rapicault/Ottawa/IBM@IBMCA Sent by: equinox-dev-admin@xxxxxxxxxxx 05/28/2003 09:13 AM

To:        equinox-dev@xxxxxxxxxxx         cc:                 Subject:        [equinox-dev] Updates on registry resolution

Hi, 

I'm moving this thread to the public knowledge. 

        PaScaL 

----- Forwarded by Pascal Rapicault/Ottawa/IBM on 05/28/2003 09:12 AM -----

Keith Kimball@IRIS 05/27/2003 04:46 PM

To:        Rafael Chaves/Ottawa/IBM@IBMCA@IBMUS        cc:        Jeff McAffer/Ottawa/IBM@IBMCA, Pascal Rapicault/Ottawa/IBM@IBMCA        Subject:        Re: more updates on registry resolutionLink

I'm impressed that you're making such good progress!!! 

I didn't understand your comment regarding changing back to original intent - do library plug-ins currently not get resolved if they have their prerequisites satisfied? Does this only happen when the library is not required by other plugins? 

I'm really looking forward to seeing your code. 

What have you do with the extension/extension point resolver? 

What are your thoughts regarding permitting/disallowing the enablement/disablement of plugins? We should discuss this with Jeff et al but my thoughts are that we should we refactor the resolver so that we can run it w/o effecting a running register (this is not too hard with the current resolver). 

Consider enable(plugin-list). My thoughts are that this should only be allowed if

• No currently resolved plugins go unresolved.
• Corresponding extension points of extensions implemented by this plugin must be able to handle dynamic plugins. For example, if the plugin provides a menu, the menu needs to get displayed.
• I'm not sure if there's an issue the other way - if a previously unresolved plugin provides an extension point, is it ok if there were dangling extensions?
  My thoughts are you run the resolver, see if a desirable end state if reached, and then carefully add the new plugins to the registry while keeping it consistent. This would take some refactoring but I believe it could be done.
  
  I believe disable has similar issues.
  
  I'm not sure this is inline with what Jeff and Pascal are thinking? Do you think we should talk later this week.
  
  Thanks for the update and great work!!
  Keith
  
  
  
  Rafael Chaves/Ottawa/IBM@IBMCA

  05/26/2003 01:54 PM

  
  

  To	Keith Kimball/Westford/IBM@Iris@IBMUS
  cc	Jeff McAffer/Ottawa/IBM@IBMCA, Pascal Rapicault/Ottawa/IBM@IBMCA
  Subject	more updates on registry resolution

  
  
  
  
  
  
  
  Hi Keith,
  
  Again, just to keep you updated with what is going on here...
  
  Here, we have made good progress. I have made the registry resolver to call the new dependency resolution algorithm instead of doing it itself, and so far I've been able to run the Eclipse registry resolution test cases with a low failure rate (8 in 189), due to known limitations in the new algorithm regarding conflict resolution and cycle detection. The good news is that some tests known to fail with the current implementation pass in the new one. The performance for running Eclipse is now equivalent to slightly better than the current implementation, and it has shown to scale well for huge registries. Also, for the incremental cases (addition, removal),  the resolution time is proportional to the number of affected plug-ins, being really fast for small changes.
  
  
  I believe I am almost ready to help you in the whole registry resolution thing. I still need to implement handling cycles/conflicts in the way the current implementation does, and improving the delta generation. After that, it is just a matter of cleaning up the code and tidying up the object interfaces so it will be ready for going public.
  
  And what about you, are things going well? Please let me know if is there anything you need that I can help.
  
  P.S.: Jeff and Pascal may be asking how the number of test failures dropped from 57 to just 8... for now, I decided to change the version selection algorithm to be compatible with the current implementation (for library plug-ins, pick only the versions which are required by other plug-ins, or pick the highest version if none is required). So, now the 8 failure cases are really problems that the previous implementation handled ok. Later, we may change it back to our original intent (resolve all library plug-ins that can have their pre-requisites satisfied).
  
  Regards,
  
         Rafael