[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Re: IdAS Registry conf call

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