Metadata support: Extensions handling
Brent Putman
putmanb at georgetown.edu
Mon Aug 12 19:43:56 EDT 2013
Recap: In the new v3 metadata resolver design, we're EntityDescriptor
centric and no longer directly expose EntitiesDescriptor data.
>From Columbus, IIRC the working idea with respect to Extensions support
was that the Extensions that appear on the parent EntitiesDescriptor(s)
of a given EntityDescriptor would be pushed/pulled down to the
EntityDescriptor. Diving into this a little further: Can we always
just indiscriminately copy Extensions that appear on an
EntitiesDescriptor to an EntityDescriptor? Are there Extensions that,
semantically, wouldn't make sense to see on an EntityDescriptor, or
where the meaning or usage would change depending on the context? I
haven't thought of a specific example yet, but I have a nagging feeling
that there might be some...
I guess one alternative approach is to have an interface for an
"extension handler". A given impl would know what to do with a given
type of extension. It's main method would take as args at least the
extension being processed and the target EntityDescriptor. Maybe it
clones it down; maybe it adds an "annotation"; maybe it skips it. A
metadata resolver would then take an ordered list of these. This
approach adds more complexity though, which I'd like to avoid.
Another related point is that XMLObject cloning is somewhat expensive.
Basically you have to marshall the DOM, if not already there, and then
unmarshall a new XMLObject tree around it. To complicate matters
further, in the current metadata processing model we usually eventually
drop the DOM after it's fetched. So in the lazy processing model (see
previous thread) where we'd be pushing/pulling the Extensions down at
caller runtime, we'd be re-marshalling things a lot. To avoid that we'd
have to preprocess all the extensions in the document, which is probably
incredibly expensive if you do wind up cloning them all and the document
is large (think InCommon or UK Federation's metadata, and all of the
trust anchors for the PKIX trust model).
Still thinking about this one, but seems this might come down to a
"lesser of several evils" choice...
More information about the dev
mailing list