[higgins-dev] You people are crazy...

["Markus Sabadello" <msabadello@xxxxxxxxxxxxx>]

I just looked at the #higgins IRC channel, and what do I see? Three different Markuses argueing with each other! :)

No we didn't have an after-conference party (although it went very well). I was offline during the day, but I just read through your whole discussion.. Let me try to summarize some of the issues.

We use XRDS for two completely different purposes:

1) To initialize the IdASRegistry. There's this one file (contextfactories.xrds by default, but that can be changed) which has a list of context factories with static configuration (if they need it). Mike aka "markus-inquisito" asks, what's the advantage of using XRDS here? You have one place where you list AND configure the context factories of your deployment, instead of the (two or three?) different mechanisms that were used before (uhm, at least I think that's an advantage).

In addition, instead of from a local file, this XRDS can come from XRI resolution, i.e. the IdASRegistry could be configured remotely. Just a few days ago, Paul and I thought of a potential new feature here: The IdASRegistry could automatically download context factories it doesn't have already. This means that you could have a Higgins deployment in which you simply give the IdASRegistry an XRI (
e.g. @higgins*registry), and it would get everything it needs on its own.

One more potential advantage of using XRDS: Reference processing. XRI resolution infrastructure has a mechanism for resolving multiple XRIs in a chain, if no suitable service endpoint can be found in the first one. For instance, you could have a local 
contextfactories.xrds file with the most basic CPs in it, and it could contain a <Ref>@novell*higgins*registry</Ref>. Therefore, your deployment would first look in its local registry, then (if nothing was found) in a Novell-hosted one, and then (if still nothing was found) we may even want to set up a global CP registry that can be tried as a last resort. (I'm not really suggesting it at this time, just pointing out the possibility).

We use this whole XRI/XRDS discovery mechanism just for IdAS CPs, not for other pluggable parts of Higgins. But we could! I don't know if we want this, tell me what you think!

By the way, as Tom aka "slim-markus" points out, XRDS doesn't change anything about the way your components are configured! It's the same XML format (wrapped in XRDS), and the call to your CP's configure() method also stays exactly the same. All that changes with the new stuff is how this configuration is discovered.

-----

2) We use XRDS for describing a context. We speak of "context descriptors". These are XRDS service endpoints that contain everything needed to create a context, i.e. context type  (to find a factory) and optional URI(s) and configuration, which may or may not be needed by the factory to create the context.

The XRDS containing the "context descriptor" comes from a ContextId. This can be a local file, a URI or an XRI. One thing to note is that if a local file or a URI is used, the context descriptor is the "default" service endpoint of the XRDS, which means that only one service endpoint in the XRDS can be used as a context descriptor, which in turn means you need separate files for each context. However, if you use XRI, there can be as many context descriptors as you want in an XRDS, because of the path element. For example, =mike/(+ldap), =mike/(+openid) and =mike/(+facebook) are ContextIds for different contexts, but they share one XRDS.
If you really feel we should be able

Hope this helps a bit. If this drives you mad, we could have a chat on IRC tomorrow!

(the real) Markus

P.S. I agree the methods in ContextIdFactory should be static. Will fix that.