Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] You people are crazy...


Having the XRDS dependencies only in configuration.xrds and not in idas.registry will not work I think, since the whole context ID stuff needs it too. Reading configuration from XRDS is just a small part of it.

What the missing sentence was supposed to say is this: If you really feel we should be able to have multiple context IDs share one local XRDS file, there would be a way to do this by simulating the "path" element of an XRI when creating an IContextId. But this is really ugly and I don't want to do this...

Regarding modification of configuration: I am not sure I understand this correctly, but isn't this something the Configuration API would have to support? I.e. have some "inverse" functionality of what the IConfigurationHandler does?

Markus

On 9/11/07, Tom Doman <tdoman@xxxxxxxxxx> wrote:
(the real) Markus,

Thank you for "stand[ing] up"!  ;)

Daniel was asking yesterday about modification of configuration contained within XRDS documents.  I don't remember if he needs to modify CP configuration or, say STS configuration but if, as you alluded to (and I did yesterday on the IRC),  all Higgins components used XRDS documents for their configuration, we'd need to understand how updates could be made.

Mike just made a comment this AM on the IRC as well that I think comes back to the "multiple file" discussion that, as you point out, arises from the fact that we're not using XRIs as context Ids ... at least I think this is what Mike is getting at ... he said:

(09:56:16) MikeMc: I would be hapier if the configuration.xrds held all the XRDS dependancies and the idas.registry didn't have any
(09:58:08) tdoman: how about we suggest that to markus?
(09:58:22) MikeMc: ok

I'll just include that to get Mike to elaborate and the first part to get Daniel to elaborate.

BTW, in #2, it looks like in the last paragraph you were about to give us a choice that I was interested to read but it looks like it got clipped ... that or you started channeling Eminem.

Tom (aka slim-markus)

>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 09/10/07 8:44 PM >>>
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.

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev



--
@freeXRI / freexri.com / try free i-names

Back to the top