Make AudioTrackInfo opt-in to improve maintainability

[Currypan1229]

Make AudioTrackInfo opt-in to improve extensibility and maintainability.
To achieve commonality/standardization, we will prepare numerous interfaces for obtaining various types of information.
It may seem excessive, but I believe this is also one solution/answer.

implement interfaces that list various information

• IAudioTrackInfo
• IAuthorInfo: nullable
  for example:

IContentInfo {
 IAudioTrackInfo getAudioTrackInfo();
 IAuthorInfo getAuthorInfo()
}

IYoutubeContentInfo extends IContentInfo {
@Override
 IYoutubeAudioTrackInfo getAudioTrackInfo();
@Override
 IYoutubeAuthorInfo getAuthorInfo()
}

Implement interfaces that can get the following information (written impl interfaces below)

• IAudioTrackInfo (getIdentifairAsString, getLength) basically
  (Since identifair can be something other than a string depending on the service, it would be clearer to add “AsString” as suffix)
• INetworkAudioTrackInfo (isStream: default=false)
• IArtworkedAudioTrackInfo (getArtworksInfo)
• IAudioSrcAudioTrackInfo ()
• IVideoSrcAudioTrackInfo (getAudioSrces: IAudioSources)
• IsrcAudioTrackInfo (getVideoSrces: IVideoSources)

Implements classes extended AudioTrackInfo interfaces
for example;

interface IYoutubeAudioTrackInfo implements IAudioTrackInfo, IArtworkAudioTrackInfo, IAudioUriAudioTrackInfo, IVideoUriAudioTrackInfo, ISrcAudioTrackInfo {
 long getLikes();
 long getDislikes();
 long getViews();
}

For features like "Like" that exist in some services, it would be better to prepare interfaces.

author track info interfaces (written impl interfaces below)

• IAuthorInfo (getIdentifairAsString, getDisplayName)
• IFollowableAuthorInfo (getFollowers: long)
  for example;

interface IYoutubeAuthorInfo implements IAudioInfo, IFollowableInfo {
 long getDislikes();
 long getViews();
}

for audio source interfaces...

IAudioSources (written impl method bellow)

• getBestAudioSource, getMaxAudioSource: IAudioSource, getMinAudioSource: IAudioSource, getAudioSources: IAudioSource[]
  IAudioSource (written impl interface below)
• IUriAudioSources (getUri)
• IBitratedAudioSources (getBitrate)
• INamedAudioSources (getName; for big, small, best)

Implement video in the same way as audio.

for artwork interfaces...

IArtworksInfo (written impl field below)

• artwork array | getMaxArtwork: IArtwork, getMinArtwork: IArtwork, getArtworks: IArtwork[]
  IArtwork (written extended interfaces bellow)
• IEmbededArtwork
• IUriArtwork
• ISizedArtwork

[devoxin]

This seems like its decreasing maintainability by making metadata classes needlessly complex. I don't think it's valuable to add extra metadata into the base interfaces with defined getters, I think this responsibility is on the source manager implementations, especially when there are non-standard fields (like views, likes, dislikes etc. These don't strictly apply to sources like Deezer, Tidal, etc.)

Extending track information has been discussed before, and it's my belief that the best way to approach this would be to place all extra metadata within a Map so that sources can pass around data that isn't defined in the spec, but with some degree of standardisation so that map keys are consistent across sources (but again, this delegates that responsibility to source manager implementations.)

There is also the question of what to do with extra fields; should they be encoded? How should they be encoded? If they're not encoded, what do you do when deserializing a track?

Lastly, naming conventions that include the type (e.g. asString, asLong etc) don't really make sense here. The types are given to you by your IDE, and if there's no possible conversion to other types then it makes that distinction useless. As an example, identifier only makes sense as a string. length only makes sense as a long, and if you need a string value then you can do String.valueOf(length).

[Currypan1229]

Thank you for your feedback on my proposal.
I found many points that I also agree with, and your comments gave me much to think about.

1, on naming conventions; asString suffixes.
I agree that the "asString" suffix is redundant and should be removed.

2, impair complexity and maintainability to impl non-standard fields, interfaces.
Your point about is well-taken.
But, my approach has merit:

• Type safety and IDE support (check in Compile-Time to prevents typos in map keys)
• Clear doc of available fields

3, on encoding and (de)serialization.
I dont have enough knowledge about it.
If there seems like problems when encoding or (de)serialize,
I can't defend my proposal if this proposal is rejected because of it.

Once again, thank you for taking the time to provide such feedback.