Changes to web flow action proposal

[Cantor, Scott]

On 4/17/13 8:16 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

>Yes, but the big difference is:  The actions and that execution framework
>(Webflow) are specific to the server-side processing case, and assume
>HttpServletRequest and -Response.  It operates on a ProfileRequestContext
>specifically geared to that case.

Yeah, that's been something I was initially punting on until I got farther
in, but I wasn't 100% sold on doing that anyway. So I think it really
comes down to just coming at the same goal from two different starting
points. I'd like to have one abstraction that operates on a more generic
input context, but we already have multiple abstractions that operate on
more strongly typed input contexts. I don't know which is a better end
state, but I'm not trying to re-engineer everything here either.

But as an example, I was thinking of possibly having different types of
ProfileAction interfaces (probably better termed Action or Handler classes
taking me back to where you are) that execute on different sorts of
BaseContext types.

>And so the MessageDecoders/-Encoders and  MessageHandlers are not, at
>least by API, specific to any particular transport, or execution
>framework.  OpenSAML ProfileActions and/or Webflow Actions are, because
>they are.

Yes, ideally I'd like them not to be, but the other option is just to have
different types of objects that operate on different types of contexts,
which is what we have now.

>I think the other big difference is that to me, the ProfileActions are
>about "profiles", not general SAML processing. At least, that's
>semantically implied by the name.

Yeah, I'm not really hung up on the name, but it comes back to the
starting point. If we changed the assumption that everything operated on
ProfileRequestContext, the naming would have to change.

>I may not be making much sense.  I'll stop rambling for the moment.
>Maybe a topic for the next call and/or I2MM.

No, I understand the point. I haven't explicitly said any of what I said
above, which is that I'm still not convinced we couldn't have one "Action"
abstraction that covers all of these different pipeline steps, but I'm not
necessarily pushing that as the better option.

I guess I should say also that I kind of was assuming we might want to try
and bend Web Flow into use for non-server side "flows" of actions, which
is what I was playing with in the command line project.

-- Scott