[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] new IdASRegistry
|
The answer to this lies within XRI resolution. When you resolve an XRI, the first step is to obtain an XRDS document, and the second step is to perform "service endpoint selection", which gives you a subset (usually one) of the SEPs in the XRDS. This service endpoint selection depends on three input parameters (path, service type, service media type) and some flags. The most interesting parameter in our situation is the path, so if for instance we have the XRI @novell*mycontexts, then the following ContextIds could result in different SEPs being selected from its associated XRDS:
@novell*mycontexts/mycontext1
@novell*mycontexts/mycontext2
etc.
The SEPs in the XRDS document for @novell*mycontexts would each have <Path> elements, so that the right SEP can be selected.
This is all already supported by OpenXRI and the new IdASRegistry. However, this service endpoint selection only works in real XRI resolution. It does not work if you use ContextIds that are URIs or local files. In these cases, the "default" service endpoint will be selected, and it makes no sense to have more than one.
So what this means is unless you use XRIs as ContextIds, you will need separate XRDS documents for each.
At least this is how it currently works. Maybe at some point we can find a way to use a query string as in your example (
http://example.com/context.xrds?<something>) to select a service endpoint, but this is not currently defined.
So I suggest to get started and test everything, we use different .xrds files for every context. I just updated the wiki page (again) with an example XRDS for a context. Once I commit the code to the CVS, there will also be example .xrds files for both the IdASRegistry and some contexts.
I don't know so much about real Higgins deployment scenarios yet, but I estimate the most common ContextIds will be XRIs anyway instead of local files.
Markus
On 8/8/07,
Jim Sermersheim <jimse@xxxxxxxxxx> wrote:
Can you provide example ContextId strings which include information that is used to differentiate between multiple SEPs in a single XRDS? If an XRDS document is allowed to have multiple context descriptors, then I'm imagining there will need to be something like:
So here's a use case (let me know if it's bogus):
I have one XRDS which contains two context descriptors. Both are of the same type, but one contexts consists of subjects that make up my AIM buddy list, and another consists of subjects that make up my employer's employees. Something in the ContextId string must differentiate these two, and there must be something in each SEP used to achieve this.
Or am I off base in thinking an XRDS will contain multiple context SEPs? Is it instead the case that a different XRDS would be used for each context descriptor?
>>> "Markus Sabadello" <
msabadello@xxxxxxxxxxxxx> 8/8/07 1:08 PM >>>
Hmm I think you are right, maybe the ABNF for "contexthttpURI" is not perfect at this point..
The point in having a file extension in a HTTP ContextId is to distinguish between different descriptor formats for obtaining the information necessary to instantiate a context. Right now the only supported format is XRD(S), but XDI will also be an option.
At the moment, the IdASRegistry and IContextId code will accept any URL as a ContextId, and it will simply expect to find an XRDS file via Yadis discovery. Yadis discovery basically means that the XRDS file can be either directly located at that URL, or referenced from there via a HTTP header or HTML HTTP-EQUIV tag.
Markus
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
