Re: [higgins-dev] new IdASRegistry

["Tom Doman" <TDoman@xxxxxxxxxx>]

Markus,

Good then!  When do you plan to proceed with your check-in?

Tom

>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 8/15/2007 2:28 PM >>>
Hello Tom,

Yes what you wrote is 100% correct, it's a good summary.

Regarding the common configuration language.. We will have a page with an
official list of context types (I'm working on that), and should we need to
agree on a configuration language for some of them, that page would be the
natural place to put it.

Markus

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