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

[Brent Putman]

On 8/12/13 7:29 PM, Cantor, Scott wrote:
> I would have assumed it indexed up front.

Nope.  I didn't write it, but it does it lazily.


>> For example, today we do not traverse the
>> whole document creating a comprehensive index of entityID ->
>> EntityDescriptor.  We wait until an entityID is requested and then we
>> find it and index it lazily.  This has advantages where a particular
>> entity is say an IdP and is only ever going to communicate with SP's -
>> there's no need to do all the work processing the IdP's in the metadata.
> I suppose, but really a big deal? Plus which there are filters that
> already walk the whole set anyway, aren't there?

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 can't imagine this being that substantial, but I've never profiled the
> SP.

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

>> As far as I can determine right now,
>> those operations can also be done lazily when a particular
>> EntityDescriptor is resolved 
>
>
> Maybe, but I can see that causing some synchronization issues too.

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.

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. 

> I guess I'm saying I can't see why preprocessing should be a bad model,
> but if we have code doing the right things now, then I don't think it has
> to change.

Well for the more worrisome stuff of pushing/pulling extensions etc down
from parent EntitiesDescriptors, we don't have anything at all.  So that
has to get written one way or another. I'll think more on the
pre-processing approach.