Function use in the IdP

[Cantor, Scott]

On 11/12/14, 8:23 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Right, but this wouldn't fall into that case.  It would be a special 
>case, as the MessageContexts vis-a-vis IOOC/PRC already are.  They're not 
>really "child contexts", they're context data, and wouldn't be 
>accessible/addressable using the *Subcontext() methods. I wasn't implying 
>that - you still only get/set them via the explicit property 
>getters/setters.

Ok, I guess I assumed having a parent meant they would be children.

>I can't immediately see a practical or (in)validity reason not to have 
>MessageContext getParent() point to its IOOC parent.  The only slightly 
>conceptually messy thing is that the IOOC/PRC would be a parent of the 
>MCs, but the MC's wouldn't really be children in the *Subcontext() sense. 
>  As long as it's clear that these are "special data children" and not 
>"subcontexts", then I think we'd be ok.  Does that sound too 
>objectionable?

It seems a bit weird, but I don't care that much.

>Yeah, we consciously decided I think we didn't in general want to do that 
>(we instead have external code copy stuff from inbound to outbound, etc). 
> I didn't yet get all the details from this thread about why Rod was 
>proposing the crosswalk, but if we want to support it, I think we can.

It's about providing Scripted implementations of Functions and Predicates 
in all the places we support functions and predicates for customizing 
code. Most of them run over the PRC by design to unify the custom code 
needed to plug in something.

-- Scott