Implement Support for RGW Subusers

[sebastianriese]

The feature has already been requested in #521. I need this functionality for implementing a new feature for rook. So I am about to implement it.

However, there are issues regarding the design of the required code.

The parameters of the API calls are serialized from the User object via reflection, the serialization API has no feature to select certain parts of the structure, so if I add the annotations to the relevant subuser fields, I will likely break existing code (since then subuser-fields will be serialized to other API calls where they are invalid when someone reuses a retrieved user object for API calls).

I'd propose to extend the serialization tooling and allow to specify fields should be included in the call and which not. This can be done by tagging groups of parameters in the field tags, or by just including plainly which url parameters are acceptable at each specific API call – this would lead to some duplication but then the data can be directly mirrored from the API documentation.

So valueToURLParams would gain a second argument (either allowedParams []string or tag string) and only select matching fields when serializing.

Any thoughts on the preferred solution?

[phlogistonjohn]

The feature has already been requested in #521. I need this functionality for implementing a new feature for rook. So I am about to implement it.

Cool, that's good to hear. @leseb for awareness.

However, there are issues regarding the design of the required code.

The parameters of the API calls are serialized from the User object via reflection, the serialization API has no feature to select certain parts of the structure, so if I add the annotations to the relevant subuser fields, I will likely break existing code (since then subuser-fields will be serialized to other API calls where they are invalid when someone reuses a retrieved user object for API calls).

I'd propose to extend the serialization tooling and allow to specify fields should be included in the call and which not. This can be done by tagging groups of parameters in the field tags, or by just including plainly which url parameters are acceptable at each specific API call – this would lead to some duplication but then the data can be directly mirrored from the API documentation.

I'm personally not as familiar with these APIs as I would like to be, so I could be talking nonsense, but I wonder if extending the User type with embedding would help here?

So valueToURLParams would gain a second argument (either allowedParams []string or tag string) and only select matching fields when serializing.

How are these field selectors supposed to work? Examples might help.

Any thoughts on the preferred solution?

I think its really great that you wanted to check in with the team on the design first. However, I do find some of the prose a little abstract and that makes it difficult for me to follow. It might help if you posted some inline code examples to help illustrate your points.

Alternatively, or in supplement to the discussion, feel free to create draft PR(s) to solicit feedback on a design early but before you personally feel that it is "done". Hope that helps a bit :-)

[sebastianriese]

Thanks for your feedback. I'll add a draft PR to make my intentions more clear. (Changing between my two proposed models should be relatively painless).

[sebastianriese]

I've added a Draft PR to illustrate my ideas: #644.

[sebastianriese]

BTW while I am at it, the reflection based URL serialization may an overhaul in other places as well.

E.g. there is recursion into structs and slices, but only if the struct is tagged with a parameter name, however, that parameter name does not end up in the encoded data (basically because URL parameters are flat). I agree that recursing into the structs without them being tagged is wasteful, but a special purpose tag like url:",recurse" may be a better solution than an ignored field name.

(Also, recursing into slices may not be what you want.)

Further, the field tag is split at , and then each part of the list is handled as a separate URL parameter name (this is very different from other uses of the field tag in the Go ecosystem, e.g. for json the first element is the name, while the latter ones act as modifiers for the encoding behaviour like omitempty).

Currently, none of this advanced behaviour is used, all url:-tags are on simple types in "toplevel" objects – so changing it won't break existing code.

[sebastianriese]

A I was wrong, the recursion feature is used, and recursion into untagged struct fields works, because Tag().Get() returns an empty string if there's no tag, so the body of for _, name := range "".Split(",") is run once (with name == "").