Print

---

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