Hi Andy,
Andrew Hanushevsky wrote:
> Hi Fabrizio,
>
>> - We have two strings that can be passed by a kxr_redirect:
>> - a "login" token which will be passed to the dest server in the
>> login phase and then cleared
>
> Correct.
>
>> - an "open" opaque info which will be passed to the dest server in
>> the open phase. This is not cleared, but can be overwritten by a
>> subsequent kxr_redirect.
>
> Almost correct. That token goes with the particular file being opened.
> So the token should be resnt on a subsequent open of that particular
> file (e.g., when reconnecting to a data server after a failure). The
> token should be cleared when going back to the redirector as the
> redirector does not need to see the token. So, "open" tokens are always
> handed out relative to a particular file and stay with that file until a
> new token is provided. A new token can only be provided by the redirector.
>
OK, this was my interpretation too.
I'd like to test the fact that the token is kept across failures, but
it should be so.
>>> Now, the redirector does not supply an opaque token the will that be
>>> taken
>>> as "no token" to pass?
>>
>> Argh, I do not understand... Please translate!
>
> What I meant to say is that if the "open" token is cleared when going
> back to the redirector then it stays cleared if the redirector provides
> no token. You would have to go out of your way to make it work otherwise.
>
> Does that explain things?
Yes, thank you. See you on Monday.
Fabrizio
>
> Andy
|