follow-up to dev call : ProfileInterceptorResult ?

[Cantor, Scott]

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

>> 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).
>
>At the moment, the flow descriptor has the functions/strategies for
>looking up the storage context and key, for reads, so I was not
>thinking the result class would have those methods.

Yes, initially I was thinking they'd be on the descriptor too. And since
there's no object up front until you read something in, they'd sort of
have to be, but then again I also was thinking that that might just be
flow specific anyway.

Again, in your example case, maybe the flow reads from a specific key
derived from the profile context using a function defined inside the flow,
and then a wildcard as a fallback, so there's no single answer to what the
key is. But a given object produced by the flow could carry along the
knowledge of what to write back to in a method or a pluggable function
inside it.

Basically, I think reading data is probably flow-specific in some cases.

-- Scott