follow-up to dev call : ProfileInterceptorResult ?

[Cantor, Scott]

On 9/19/14, 1:26 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:

>Scott,
>
>Were you thinking that :
>
> ProfileInterceptorResult (which probably could loose the "Profile"
>prefix) would be an interface ?

Yeah.

> The "master" post-authn-flow (in system/flows) would have actions to
>read|write the result from|to storage ?

At least write. Read maybe depends on too much flow-specific knowledge
(there might even be multiple records read, like in your example of a
wildcard followed by a specific one).

And it isn't essential that it be in the parent flow, just a possible
improvement.

> ProfileInterceptorResult would be a field of the
>ProfileInterceptorContext ?

Sounds likely, analagous to AuthenticationResult, which also gets
serialized at a particular spot.

> Is the following class what you were thinking of generally, or something
>else ?
>/**
> * Represents the result of a profile interceptor flow intended for
>storage by a
> * {@link org.opensaml.storage.StorageService}.
> */
>@Context("storageContext")
>@Key("storageKey")
>@Value("storageValue")
>@Expiration("storageExpiration")
>public class ProfileInterceptorResult {

What I was suggesting is more like an interface with accessors for ID (the
flow ID), creation time, expiration time, and probably methods to get the
context and key (similar to what you're putting there).

Each flow descriptor would carry the StorageSerializer to use, and the
parent flow would just call the result object methods and then call the
serializer to get the value to store, and probably would just do if
(!create succeeds) { update }.

I haven't used the annotations at all, so I don't have much advice on
that, I don't think about it that way.

-- Scott