-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: changed from alllowercase to kebab-case for metadata keys #4695
refactor: changed from alllowercase to kebab-case for metadata keys #4695
Conversation
Otherwise it's impossible to convert to a different case in an automated way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure we can change that? Wouldn't that break backwards compatibility?
It's only for the metadata that @dschmidt and I introduced (audio, location, image, photo) and that is unused so far. But yes, it's a breaking change... don't know how to continue here. At least for |
@@ -1147,19 +1148,11 @@ func mdToPropResponse(ctx context.Context, pf *XML, md *provider.ResourceInfo, p | |||
appendMetadataProp := func(metadata map[string]string, tagNamespace string, name string, metadataPrefix string, keys []string) { | |||
content := strings.Builder{} | |||
for _, key := range keys { | |||
lowerCaseKey := strings.ToLower(key) | |||
kebabCaseKey := strcase.ToKebab(key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The keys are hardcoded above. Why even lower or kebap case them? IMO isVariableBitrate
should just remain camel case. Any reasons against that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kobergj wanted to achieve a somewhat consistent format for keys in the propfind response. From a client perspective that is a good thing to achieve. A mix of kebab, camel and snake case in the keys is annoying as hell...
However, my strongest need is, that I can convert the keys easily to a different case so that they match an interface of mine. Types/interfaces in web are all camelCase, so I need to be able to convert as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only thing I'm concerned about is backwards compatibility. Let's maybe not backport it to 5.0
to be safe?
Changed from alllowercase to kebab-case for metadata keys in propfind responses.
Otherwise it's impossible to convert to a different case in an automated way.