Function use in the IdP

[Brent Putman]

On 11/12/14 2:19 PM, Cantor, Scott wrote:
> On 11/12/14, 7:09 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>> Have to think more - maybe there's a way to solve - like just overriding 
>> and making the setParent(BaseContext) public on MessageContext.  Then 
>> wherever we set the MC's on the PRC, just also set the parent explicitly.
> Well, the problem sort of was that the navigation model is class-based, 
> and I didn't think you could set two child contexts of the same type on 
> the parent.

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.

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 is true that if getParent() worked, the way back down could be via the 
> message context properties and not with getSubcontext(), 

Right, it's implied that crosswalking code would have to check and cast
getParent() to IOOC/PRC and then access via
get(Inbound|Outbound)MessageContext, not via subcontext methods.  No
access via the latter.


> but I just didn't 
> think it was a good idea to call setParent() if you end up with a messy 
> situation due to the class duplication.


Right, the duplication and Class literal indexing was (one of) the
reason(s) they aren't subcontexts.  With the above, though, I don't
think there's any duplication issues.  BaseContext setParent just sets
that reference, it doesn't try and manage the link in the other
direction by calling addSubcontext, etc.  That's intentional - it has
'protected' access and not meant to be called externally.  We can do it
here, however, since MC and IOOC are in the same package.

> It hasn't come up because we were careful to avoid factoring functionality 
> in ways that required getting up to the root and back down from the 
> message handlers.

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.

I'll hold off checking anything in pending further discussion.  The
changes are trivial if we decide to support it.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20141112/dc8e08fc/attachment.html