| Re: [higgins-dev] Re: IdAS Registry conf call |
|
So, I'm going to summarize again, what I propose, along with what I see as two possible cons. Then I propose that we adopt my proposal until someone sheds compelling light on a reason not to do it.
My proposal is to use the "Java class name of the Context Provider's IContextFactory class" in place of cpid, and remove IdASRegistry.
Note that this does not preclude two CPs from being similar (i.e. two different JNDI CPs), nor does it preclude a CP from creating multiple contexts, each pointing at / representing different data. We're only talking about the factory here, not what it produces. This also doesn't preclude us from pairing a factory instance with some factory-level configuration data either (though that would have to be done at the context-config level now)
Con 1: In a world where one CP needs to have multiple instances of a context factory, each differentiated by per-factory configuration data, this approach might be more cumbersome. I have to dig deep to contrive scenarios that involve different factories per CP.
Con 2: Something along the lines of what Greg/Valery are saying. I'm not sure what it means, or what the consequences are.
So, at least for me, it feels like I'm inventing reasons not to adopt my proposal at this point, which is why I feel it's best to use the factory class name for now, and change later if someone brings up a compelling reason.
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 2/13/07 12:12 PM >>> This is the direction I assumed that would lead to some possible contention. My problem is that I understand it less than you, Greg. I knew Valery had brought up some issues, but I couldn't make out exactly what was being said (our phones need an overhaul I think).
In fact, my understanding of how each Higgins component is supposed to work within the eclipse framework is largely a mystery to me. If this is going to affect/drive our component architecture, I/we need to maybe take a break from moving too far forward before coming to grips with this.
Do people think we need to step back and get us all on the same page regarding eclipse plugins/extension points (I don't even know if these are two terms for the same thing :)). If so, does anyone have time to sort of draw a mental map of how the Higgins architecture is affected by and works with eclipse in this way?
Jim
>>> Greg Byrd <gbyrd@xxxxxxxx> 2/13/07 8:09 AM >>> Just to play devil's advocate.... Multiple LDAP sources could mean multiple IContext instances, not necessarily multiple CPs. Why would you need multiple instances of the same IContextFactory class (within a single user's view of the world)? Different CPs should implement different classes for their context factories, or at least that's my expectation. Valery mentioned that, in the Eclipse case, one could have a single class implementing multiple Eclipse extension points. I'm not sure I understand this case. I thought that there would be a single extension that represents a Higgins CP, and certainly there could be multiple classes that implement that extension point. What situation would lead to the other case, where multiple extension points are used, all implemented by the same class? (I was planning to look into this some more. The point of an extension is that it's a standard name for some feature. If you provide different extension points for each flavor of that feature, it sort of defeats the purpose, right? Because the programmer needs to know the names of all the flavors/extensions up front.) ...Greg Mary Ruddy wrote: > Yes, I'm in the same boat with Mike. For example a Higgins enterprise > implementation would likely need to pull data from multiple data > sources that used LDAP. The original Higgins concept thought that > multiple instances of a CP was a requirement. > > > -----Original Message----- > From: higgins-dev-bounces@xxxxxxxxxxx > [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael McIntosh > Sent: Tuesday, February 13, 2007 9:35 AM > To: Higgins (Trust Framework) Project developer discussions > Cc: 'Higgins (Trust Framework) Project developer discussions'; > higgins-dev-bounces@xxxxxxxxxxx > Subject: Re: [higgins-dev] Re: IdAS Registry conf call > > I may not fully understand - but I have reservations about using the CP > factory classname to identify an instance of a CP. > I think I'd like to be able to configure a system using two LDAP CPs, > each > configured to point at a different LDAP Server. > > Thanks, > Mike > > > higgins-dev-bounces@xxxxxxxxxxx wrote on 02/12/2007 11:36:27 PM: > > >> The one open issue which must be resolved is the datatype of the >> cpid (the thing that identifies a context provider). It has been >> suggested that this should just be the classname of the CP's >> IContextFactory. At this point, I favor this solution, and further >> note that if we see no real need for a CP factory config data (apart >> from what could be added to the contextConfig), then there's no >> longer a need for IdASRegistry as proposed -- leaving us with only >> one registry again. >> >> Jim >> >> >> _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |