 |
 |
Ah, I see what you are saying. The authzfunparms itself might be an incomprehensible blob, much like vomsfunparms. This is more complicated simply because each of these plugins uses an arbitrary syntax, for no particularly good reason. The answer is we could given a template. So,I see that
-vomsfunparms:certfmt=pem|vos=atlas,cms,dteam|grps=/atlas,/cms,/dteam|grpopt=10|dbg
is sort of an ungodly mess. Here we know that '=' is the key-value separator (as opposed to colon) and the option separator is '|' (as opposed to space) and there is no leading character (as opposed to dash). So, yes, if I were told that's the blobbing template I could apply it when you see multiple gsi.authzfunparms directives to construct that blob. The question is where does the template come from? The config file? A builtin template? From the protocol itself? If it's a builtin template then there would need to be a way to override it if you wanted to use another plugin that has some other kind of template going on. If it comes from the protocol then the protocol would have to instantiate a blobber itself and provide the template but then each plugin would have to do the same. authz and voms plugins really use different syntax based on who wrote the plugin? Do we have multiple instances of this going on already? If not, we can kill this divergence now before it starts I think.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1