[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ProbableSpam]Re: [equinox-dev] [prov] Thoughts on the engine


Another possible approach is to have a single root IU, whose prerequisites have filters based on different classes of users.  Since the filters on required capabilities are evaluated at install time based on properties in the profile, the result would be that the same root installed into different kinds of profiles would yield different install trees. This allows per-user customization without having to build too much smarts into the repository itself. Of course, this does require that the profile be seeded initially with the correct properties.




Pascal Rapicault/Ottawa/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx

08/17/2007 08:42 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>, equinox-dev-bounces@xxxxxxxxxxx
Subject
[ProbableSpam]Re: [equinox-dev] [prov] Thoughts on the engine





I'm sorry but I don't understand what you are trying to achieve, nor what
the problem is.

The SDK IU is an artificial root that we create at metadata generation time
to provide one entity to install and get the sdk. The presence of this IU
does not prevent you to define "James SDK" IU. You should be able to
compose and/or install directly from the other IUs since they are
completely independent.
For example if you were to install the "org.eclipse.core.runtime" IU you
would get it and all its prereq, thing that we were not able to do before.


PaScaL


                                                                         
            James D Miles                                                
            <jdmiles@xxxxxxxx                                            
            om>                                                        To
            Sent by:                  Equinox development mailing list    
            equinox-dev-bounc         <equinox-dev@xxxxxxxxxxx>          
            es@xxxxxxxxxxx                                             cc
                                                                         
                                                                  Subject
            08/16/2007 05:16          Re: [equinox-dev] [prov] Thoughts  
            PM                        on the engine                      
                                                                         
                                                                         
            Please respond to                                            
                 Equinox                                                  
               development                                                
              mailing list                                                
            <equinox-dev@ecli                                            
                pse.org>                                                  
                                                                         
                                                                         




     Do you mean that some operations must be done with the actual user
     being
     identified?
     Yes, if you are sharing an install (multiuser), each user must be
     configured separately. And to your point in <tangent 2> each user may
     be managed differently.

     <cotangent 2>
     My thoughts were along these lines. Currently we have an IU with id
     "sdk" in the sample. This sample provides no capabilities but only
     list requirements to be installed. While it should remain an IU it
     should be categorized by subclassing or creating an interface for all
     of these: IU fragment, IU, etc. That would allow another abstraction
     that manages a description ("sdk") of what can be installed. These
     could me managed on a per user basis if that is what is wanted.
     </cotangent>


(Embedded image moved to file: pic08335.gif)Inactive hide details for "Tim
Webb" <tim@xxxxxxxxxx>"Tim Webb" <tim@xxxxxxxxxx>

                                                                         
                        "Tim Webb"                                        
                        <tim@xxxxxxxx                                    
                        om>                                              
                        Sent by:      (Embedded image moved to file:      
                        equinox-dev-b pic03420.gif)                      
                        ounces@eclips                                  To
                        e.org                     (Embedded image moved  
                                                  to file: pic31381.gif)  
                                                  "Equinox development    
                        08/16/2007                mailing list"          
                        03:40 PM                  <equinox-dev@xxxxxxxxxx
                                                  g>                      
                                      (Embedded image moved to file:      
          Please respond to           pic15965.gif)                      
  Equinox development mailing list                                     cc
      <equinox-dev@xxxxxxxxxxx>                   (Embedded image moved  
                                                  to file: pic13816.gif)  
                                      (Embedded image moved to file:      
                                      pic31066.gif)                      
                                                                  Subject
                                                  (Embedded image moved  
                                                  to file: pic15739.gif)  
                                                  Re: [equinox-dev]      
                                                  [prov] Thoughts on the  
                                                  engine                  
                                                                         
                                                                         
                                      (Embedded image moved to file:      
                                      pic26985.gif)                      
                                             (Embedded image moved to    
                                             file: pic08985.gif)          
                                                                         
                                                                         


     <tangent>
     That said I must admit that I'm not super happy with this solution
     since to
     make such a "fetch only" operation usable, either the director would
     have
     to expose a "fetch" operation (but it would also have to expose a
     "install"
     operation to solve the other pb mentioned by James), or one would
     have to
     either author its own director (or at least extend the current one)
     which
     is something we want to avoid. In the light of recent discussions
     with Tim
     and others, I wonder if the director should not become just a planner
     that
     returns a bunch on operations that needs to be performed. The results
     of
     this planner would then be passed on to the engine and a "target"
     phase
     could be specified. For example:
     EngineOperation[] op = director.install(ius, profile1)
     engine(op, "fetch"); //This means do the operations but stop at
     fetch.
     </tangent>

This actually makes a lot of sense to me. It addresses multiple concerns
including being able to present to the user an accurate statement of how
much work needs to be performed, as well as allowing for much easier re-use
in server-side scenarios.
     Do you mean that some operations must be done with the actual user
     being
     identified?

<tangent id="2">
While probably not where you were going with this one, mentioning per-user
operations reminded me of another flow we were planning to support in Maya
where some software would only be available to certain users. If we were
using user-aware repositories as part of the resolution process, would we
do the filtering inside the repository? If so, how would we handle this in
a multi-user scenario especially when a director/planner is being used
server-side? Ideally I'd like the flexibility of filtering which software
is available to which user, but currently the implementation / APIs do not
allow passing of any handle or request-identifier to the repositories to
aide in determining which software is available. Thoughts?
</tangent>_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
(See attached file: pic00393.gif)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Attachment: pic08335.gif
Description: GIF image

Attachment: pic03420.gif
Description: GIF image

Attachment: pic31381.gif
Description: GIF image

Attachment: pic15965.gif
Description: GIF image

Attachment: pic13816.gif
Description: GIF image

Attachment: pic31066.gif
Description: GIF image

Attachment: pic15739.gif
Description: GIF image

Attachment: pic26985.gif
Description: GIF image

Attachment: pic08985.gif
Description: GIF image

Attachment: pic00393.gif
Description: GIF image