Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] new IdASRegistry


Thanks, that clarifies things some.  Yes, I was talking about configuring
context factories and I think I see how the factories would get their
factory specific configuration but I don't see how the contexts produced
by those factories would get their configuration.

Today, my context factories do some "resolution" on the contextRef
URI they are passed.  My context factories are all
IConfigurableComponents and they receive the global and component
maps.  When they are asked to create a context, they expect a
contextRef with an "?id=" in it which identifies what I've been calling
a "Context" which I've also held synonymous with it's associated
configuration.  Should it be?  I've felt so because the configuration
is what differentiates this context from another one (regardless, btw,
of what CP implementation might be able to read and use it).

Anyway, I see in your examples how we would resolve an XRDS
document, but not, as I'm trying to describe above that we're, in
essence of doing now, how to resolve an SEP within an XRDS document
this contains configuration for a specific Context.

Also, let me point to an example configuration I'm using in one of
my unit tests today so you can see how I've got the configuration


>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 8/8/2007 12:36 PM >>>
Hello Tom,

See inline.

On 8/8/07, Tom Doman <TDoman@xxxxxxxxxx> wrote:
> Markus,
> All right, I had a chance to review the relevant Wiki pages and I think it
> all
> looks pretty good to me.  I just have a question about converting over to
> it.
> I guess I'm confused about the code snippet in the example at
> under
> ConfigurationHandler for XRDS.  Perhaps what I'm doing in my JUnit tests
> today will go away in favor of the new registry.  Since my test are only
> concerned with exercising the Context Provider implementations, maybe
> the new registry will do everything I need and those code snippets don't
> apply.

[Markus] What exactly confuses you here? You don't have to use this
ConfigurationHandler directly, it is only used by IdASRegistry to extract
configuration for context factories, and it is also used by IContextId
implementations to extract configuration for contexts.

Today, I'm emulating what a client application would do to configure the
> system using the current Higgins configuration APIs which is similar to
> the
> example minus the specification of an SEP.  If I understand correctly, I
> can eliminate that code by simply using an XRDS document as described
> in the IdASRegistry section of the same page.  Am I on the right track
> here?

[Markus] Are you talking about configuring context factories? If yes, you
are right, the IdASRegistry will automatically configure the context
factories once they are needed, but it will not touch any other components
in the Higgins architecture.

However, it should not be too much trouble to expand this "registry"
functionality to other pluggable components as well, if that is needed.

If so, that would be great, but I don't see an example showing how
> the registry instance is primed with the specified XRDS document.  What
> would be my choices for location?  A URI/XRI?

[Markus] Good question, I guess I should have been more specific about this
on the wiki page. By default, the IdASRegistry looks for a file named "
contextfactories.xrds" in the classpath, but this can be changed by calling
setContextFactoryDiscovery() on the registry, passing it any implementation
of the IDiscovery interface. Here are some examples:

FileDiscovery("/mypath/myregistry.xrds"));   // this reads the registry
configuration from a local XRDS file
registry.setContextFactoryDiscovery(new StreamDiscovery(myInputStream));
// this reads an XRDS file from a stream
registry.setContextFactoryDiscovery(new YadisDiscovery("";));  // this uses Yadis
discovery to obtain an XRDS file from a URI
ResolutionDiscovery("@higgins*registry"));   // this performs XRI resolution
to obtain an XRDS file

I think there was consensus on the list that in most deployment scenarios
this configuration will simply be read from a local file, so I chose the "
contextfactories.xrds" as default. The most sophisticated scenario would of
course be to use a URI or an XRI (such as @higgins*registry). In this case,
the registry configuration could be dynamically managed without having to
touch existing Higgins deployments. Maybe in a future version the
IdASRegistry could even dynamically download context factories that are not
yet installed locally?

I added a bit more information about this on the ContextDiscoveryComponents
page in the "IdASRegistry" section.


> Tom
> >>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 8/6/2007 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:
> 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 

Back to the top