Re: [higgins-dev] new IdASRegistry

["Tom Doman" <TDoman@xxxxxxxxxx>]

Markus,

Okay so that's where Greg's comments about a common configuration
language come in since the context factories and contexts are not joined by
a specific CP implementation.  That's all right with me for the time being,
we can address that when there are multiple implementations of given type
or the types are flexible enough to be more specific (pardon me for
butchering the syntax but something like "$context+ldap+novell" vs.
"$context+ldap+ibm" to distinguish different implementations).  If so, this is
a minor discussion for a later time to choose one of those two approaches.

Yeah, I'm using local files for my unit tests so I'll have separate ones for
each but it's cool to have a lot of deployment choices for production
environments, I like it.

So, let me just make sure I have the process down here:

I have my context factories defined in the default contextfactories.xrds and
those are processed when getInstance is first called on the IdASRegistry.
Each context factory defined therein has it's configure method called with
the configuration contained in it's <Configuration> element for factory
specific configuration (fwiw, currently, I don't have any configuration of
this kind but I plan to).

To get a context, from my local context file, I do something like this:

IContextId contextId = ContextIdFactory.getInstance().fromFile("testcontext1.xrds");

The act of getting the IContextId causes the context configuration in the
<Configuration> element to be processed and placed in the Map inside the
IContextId for use by the context when it is created by the context factory.

Correct?  If this is how it all breaks down, I'm ready to go ahead and move
forward with conversion.

Tom

>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 8/14/2007 6:33 PM >>>
Hello Tom,

You are exactly right about the examples.. The connection between context
factory configuration and context configuration is made via the "context
type" (the contents of the <Type> elements). This is the "core
functionality" of the IdASRegistry. A context factory can have multiple
<Type>s (meaning it can open different context types), and a context can
also have multiple <Type>s (meaning it can be opened by context factories
supporting either of these context types).

The context factory XRDS is only a single document. This is the XRDS which
IdASRegistry uses to initialize itself. It contains one service endpoint for
every context factory.

The context XRDSes should be different documents IF they are read from a
local file or from a URL. If they are obtained via XRI resolution, there
could be multiple context descriptors (service endpoints) in an XRDS,
because of the path component of an XRI.

Markus

On 8/14/07, Tom Doman <TDoman@xxxxxxxxxx> wrote:
>
> 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 
> >
> >
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
>