| RE: [higgins-dev] What's in a name? |
|
I created http://spwiki.editme.com/ContextRef in an attempt to keep track of what we’ve agreed on as well as the open issues. I added Raj’s method as an open issue.
-----Original Message-----
Ok, so the Context Ref URI provides sufficient information (either directly or indirectly) to open a context (ok, need the AuthN stuff too), and that context will be equal regardless of instantiating provider. I like it.
For the purposes of where I was going (grok what's in the URI), the second part (two same contexts may result from two different Context Ref's) doesn't worry me. Is it enough to warrant (as Raj suggested) some method for testing for sameness? I'm not sure what the use case for needing to know this are? Maybe that should just be another TODO and we can visit it when it comes up as a more tangible issue.
Jim Jim wrote:
In light of the "Sameness of Context" thread, I would argue that ContextRef #1 below lacks information needed to be considered to point at a single context. Two providers may produce context instances based on that reference where both contexts are very different.
ContextRef #1 was simplified. But if I make it even a bit more complicated looking:
I could argue that it somehow does encode everything necessary to identify a context. As for the somehow.There may be lookups/indirection based on substrings like "ldap347" and "4f544", etc. for a context provider to know how to take this URI and serve up the implied context.
That's based on my assumption that two equal ContextRefs will produce two equal contexts. If my assumption is off, I need to re-adjust my thinking.
Agreed. Two equal ContextRefs will produce two equal contexts. [Though, just to be precise, two different ContextRef URIs may also produce the same context too. There is no assumption that there is only one way to reference a Context]
Jim,
In the past ContextRefs have been implemented using a two part identifier. The first part uniquely identified the provider/factory the second part was the unique id of a context managed by that factory. This is what you call 1) in your email below.
We want to move towards your 2). We want the IdAS user to be able to request that it open a Context by URI without having to know which provider/factory to use a priori (use case #1 here).
Whereas in #1 the form of the context id part was entirely up to its "creator" provider/factory, now we envision a ContextRef being a URI formatted string that may be used by (or at least examined by) more than one provider. This raises lots of questions.
Consider the following ContextRefs:
IdAS can ask each registered provider whether or not it can open this ContextRef. Provider A may respond that it can open #1 above and Provider B may respond that it can open both #2 and #1.
Questions:
BTW, I envision some context providers will be developed that use XRIs for their ContextRefs.
-Paul
Jim wrote:
I wonder if we have different ideas about what's in the Context Reference URI.
1) Until lately, I thought it contained at least the name of a context factory, plus the name of a context. I wasn't sure what either of these looked like, just assumed they were both required.
2) From discussions, I think some others think it only holds the name of a context (in some form). This allows one URI to be used against multiple factories to produce the same Context (albeit possibly via different IContext instances, using different config and policy, using different AuthN, and thus semantically different).
3) Tom assumed it was a pointer into a context definition file. In our world, that segment of the definition file names the factory used to produce that context.
Jim |