The Context page only talks about the abstract notion of a
context (i.e. it doesn't explicitly talk about the methods of iContext), where
the ContextProvider gives more details regarding the roles of the
IContextProvider interface.
We should probably go one way or the other in that regard,
but either way, we need to be able to agree on those pages.
Jim
>>> "Tom Doman" <TDoman@xxxxxxxxxx> 7/20/06 11:36 AM
>>>
This is good, it's helping me see that perhaps I'm thinking of Context
Providers and Contexts differently that what you guys have come up
with.
So, a few questions:
1. I guess I had thought of Context Providers as being providers of a
specific kind of context. For example, an LDAP Context Provider that
provides Contexts to LDAP endpoints or a Join Context Provider that
provides Contexts to other Context Providers which, say, join data from
LDAP, SQL, and Liberty endpoints. How far off the mark am I here?
Some
of what was discussed on the call as well as these use cases seem to
indicate that any given Context Provider can provide a Context to the
same URI. And perhaps the Context Providers then are just different
vendor implementations of how to get a Context for a given URI. I'm
sure much of my thinking is guided by what we've implemented in Bandit
and I'll send the promised examples under separate cover. I went
through the Java Docs yesterday but I'm still unclear on exactly what
Context Provider and Context are. In addition, as per #2 below, how
they can be used to encapsulate or join a variety of disparate data
sources and data formats.
2. Use case number 4 makes me wonder what it means to "import a
Context" but I assume that'll become clearer in Greg's description.
It
does, however, raise an additional use case I'd like to see added and
detailed. That is, the case where the user wants a Context which
gathers identity data for a variety of data sources, each of which may
have data represented in a distinct specific format (e.g. LDAP, SQL, XML
File, etc.).
3. A clarification on what end points are would also be helpful. We
have envisioned creating and combining Higgins Context Providers (or
C ontexts ... still fuzzy, see #1) to achieve non-endpoint type
functionality such as:
a. name mapping, in and out
b. policy based manipulation of requests based on data passed in the
request such as action, name, name type, and data (ie. if the name
specified is an LDAP name, resolve it in these contexts but not in
these, etc.)
c. massaging requests, in and out
i. mapping requested attributes to their appropriate counterpart
in destination contexts and back
ii. restriction of what is allowed to be read in a destination
context
iii. decoration of data returned (ie. where was this data gotten
from?)
Will the Higgins Context Provider model allow us to do these kinds of
things in separate Context Providers?
Thanks,
Tom
>>> Greg Byrd <gbyrd@xxxxxxxx> 7/20/2006 10:56 AM >>>
Here are some use cases for IdAS, relevant to our phone discussion
today. In a later email, I will try to de scribe a way to use the
Provider class (and its relatives) to implement these use cases.
1. User has URI of a Context and wishes to open it. There are no
constraints on the provider.
2. User has URI of a Context and wishes to open it using a specific
provider.
3. User wishes to determine which providers are available for a
particular Context (URI).
4. User wishes to import a Context whose data is represented in a
specific format (e.g., LDAP).
5. User wishes to find out which Contexts are available using the
currently-installed providers.
Anyone with additional use cases should post them to the list.
...Greg
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________< BR>higgins-dev mailing
list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
