The purpose of this JIra is to get delegation tokens without duplication for MR. All the additional requirements that you state with "I want " "I want" "I want" belong in a different jira.
It's true that the conversation has recently morphed into that, but the original description is more broad.
>I want this filesystem's delegation token - getDelegationToken(renewer)
I already argued above that i disagree that this is a reasonable API since a multi-filesystem cannot implement it and furthermore I disagree that a multifilesystem like viewfs should return null.
The proposal I'm putting forth is: the distinction is that a filesystem should not implement getDelegationToken unless the filesystem itself has a token, ie. it needs to make an authorized connection. ViewFileSystem does not make a connection, thus it does not have a distinct token. It does however have contained filesystems that makes connections so that's what getDelegationTokens operations on. The method should be common, ie. a filesystem will not implement this method.
If there isn't a getDelegationToken, then I believe we are forced into a tightly coupled design. Ie. every filesystem needs to bracket their code that obtains a token with copy-n-paste code. Is this desirable? If there is a primitive getDelegationToken, then the standard/common code (getDelegationTokens) to acquire tokens will perform the bracketing, thus confining the logic to one place where it can be changed in the future.
> I want all delegation tokens used by this filesystem - getDelegationTokens(renewer)
Pass in a an empty credentials to addDTs(renewer, emptyCredentials).
That's what my patch does, but let's say I have a credentials with some tokens. I want to acquire any missing tokens, yet I want to know what those tokens are so I can log that I got them and/or I need to do some special processing on them. Ie. TokenCache. How would I do that?
I agree that addDTs(renewer, cred) is a weird API, but your getDelegationTokens(renewer, creds) is equally weird.
It's not mine, it was already there. I argued against it in an earlier jira, but after further thought, it seems reasonable.
What if we make getDelegationToken a protected method to avoid external calls? The only public facing api will be getDelegationTokens(renewer, creds)?