Metadata support: duplicate entityID detection; resolver lazy eval vs. preprocessing

[Cantor, Scott]

On 8/12/13 8:19 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>I suppose the entityID index time isn't that big a deal, and we do have
>filters that walk the tree.  I suppose I was thinking mostly about all
>the other potential pre-preprocessing which would be more expensive than
>a simple tree walk and building a Map<String, EntityDescriptor>.  Or I
>guess would be Map<String, List<EntityDescriptor>> if we want to support
>same-document duplicate detection.

I use multimaps, because I allow for duplicates that don't actually
overlap (e.g. different roles). That's another reason I overlapped the
role and entity search interface. I can do a search for a specific role
and protocol, and skip matching entityIDs that don't support the right
other criteria.

>For the record, what do the SP's metadata providers do?

Index up front, but reloads are in a background thread now, even for local
files.

>True, we would have to lock on the EntityDescriptors in some fashion.
>So I guess there's at least one tradeoff here between pre-processing
>cost upfront vs. locking at runtime.

It's not the locking cost so much but the complexity and risk that concern
me with any scheme like that.

>Btw, same locking issue with the MetadataCredentialResolver processing
>creds and storing them as XMLObject "annotations".  I can't see us doing
>that as pre-processing in any case, since it's external to the metadata
>providers; otherwise we're back to the issue of building key/cert/etc
>processing logic into layers where it probably doesn't belong.

Yes, true.

-- Scott