Re: [higgins-dev] new IdASRegistry

["Tom Doman" <TDoman@xxxxxxxxxx>]

Markus,

Okay, so the context factory XRDS document and the context XRDS
documents should all be separate documents?  In other words, one
context factory and two contexts would yield three XRDS documents?

With http://wiki.eclipse.org/ContextDiscoveryComponents#Example_3
being an example of context factory XRDS configuration and
http://wiki.eclipse.org/ContextDiscoveryComponents#Example_4
being an example of context XRDS configuration?

How would a context factory as defined in Example 3 know that it
could produce a context as defined in Example 4?  Should there be
something in the configuration of Example 4 that indicates which
factory can produce it or is that connection made based solely on the
"Type" definition is each example?

Tom

>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 8/8/2007 8:27 PM >>>
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:
> http://example.com/context.xrds?<something<http://example.com/context.xrds?%3Csomething>
> >
>
> Also, the example at http://wiki.eclipse.org/ContextDiscoveryComponents#Example 
>  doesn't contain anything that could be used to differentiate it from
> another SEP in the same XRDS.
>
> 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
>
> On 8/8/07, Jim Sermersheim < jimse@xxxxxxxxxx > wrote:
> >
> >  In the ABNF, the contexthttpURI allows something like http://example.com/context.xrds?somequery=something 
> >
> >
> > I suspect the query would not be expected when the descriptor-ext is set
> > to .xdi or .xrds.  Would that be a correct assumption?
> >
> >
> > >>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 8/6/07 7:49 AM >>>
> > Hi all,
> >
> > Since I didn't get much feedback about the new XRI/XRDS based
> > IdASRegistry, I am wondering if you guys (especially Jim and people working
> > on Context Providers) had a chance to look at it.
> >
> > I would like to check it in soon so we can get this running, and it will
> > definitely break a few things. The changes will include replacing
> > ContextRefs with ContextIds in the IContextFactory interface.
> >
> > The relevant Wiki pages are:
> > http://wiki.eclipse.org/ContextId 
> > http://wiki.eclipse.org/Context_Discovery 
> > http://wiki.eclipse.org/ContextDiscoveryComponents 
> >
> > If noone objects I propose to commit this in a few days.. Let me know if
> > I can help with anything.
> >
> > Markus
> >
> >
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx 
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> >
> >
>
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
>
>