[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Re: IdAS Registry conf call
|
I think there is a point of confusion/disconnect around what a context provider id (cpid) is meant for, what context id (cid) is for, etc.
I think all of us understand the need for context ids and that it needs to be not a class name - for example, we can represent that by a URL or EPR. It cannot be the class name.
I wonder if the use case for cpid is around the need for context provider to be identified to get an instance (as in factor pattern) .. in which case, we just do that - get an instance from factory based on a type, and not call it "cpid" - because it is not an identifier (atleast I do not think of it as an identifier).
Raj
![Inactive hide details for Greg Byrd <gbyrd@xxxxxxxx>]()
Greg Byrd <gbyrd@xxxxxxxx>
Greg Byrd <gbyrd@xxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
02/13/2007 10:09 AM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx> |
|
|
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
