Skip to main content

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

Hello Tom,

See inline.

On 8/8/07, Tom Doman <TDoman@xxxxxxxxxx> wrote:

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

[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

[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:

registry.setContextFactoryDiscovery (new 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
registry.setContextFactoryDiscovery(new 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.



>>> "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.


higgins-dev mailing list

Back to the top