search

sandreas / tone

tone is a cross platform audio tagger and metadata editor to dump and modify metadata for a wide variety of formats, including mp3, m4b, flac and more. It has no dependencies and can be downloaded as single binary for Windows, macOS, Linux and other common platforms.
https://pilabor.com
Apache License 2.0
410 stars 17 forks source link

Support JSON response when tagging #29

Closed advplyr closed 1 year ago

advplyr commented 1 year ago

When tagging there is only a response to be used in a CLI.

Also, when the tag fails there is no way to check if the tag failed since everything is written to stdout.

sandreas commented 1 year ago

That`s a good point. I'll see what I can do here.

sandreas commented 1 year ago

@advplyr So I started to implement this yesterday and the following questions came up:

My current implementation plan is:

The patch plan is not ready yet and maybe change to full result because I have to check a library that offers the JsonDiff stuff... I would also use the "NON RFC" Patch variant, although I love RFCs it is not helpful to see what operations must be applied in the terminal but only the "changeset"...

advplyr commented 1 year ago

@advplyr So I started to implement this yesterday and the following questions came up:

  • What would you expect, when a file is tagged with parameters, that do not change anything?

Having some indication that the process executed is helpful. I'm not sure what that would be though, so as long as the exit code is 0 and nothing is returned then I can work with that.

  • Would you expect the full metadata information result after tagging or only patch information?

I think it is perfectly fine to return the full metadata information. For Abs when applying the updates to objects we will be comparing the new details with the old ones anyway.

However, returning just the patched information is probably more friendly to other clients.

If it saves you from including another package in the library then I would say just return the full metadata.

  • What would you expect on errors besides return code different from 0? (e.g. file cannot be updated, disk full, etc.)

No output on stdout and error message in stderr. Ideally the error message is something I could show the user.

If you have more complete error data then that would require a JSON object. Like some APIs return a user-friendly message and a more verbose message for the devs, but I doubt that is necessary here.

My current implementation plan is:

  • no changes => no output
  • never a full result, only patch information (its better to see what changed then getting bombed with information)
  • error with return code > 0 and output error message on stderr (stderr can be ignored in wrappers, but at least you may understand the problem)

The patch plan is not ready yet and maybe change to full result because I have to check a library that offers the JsonDiff stuff... I would also use the "NON RFC" Patch variant, although I love RFCs it is not helpful to see what operations must be applied in the terminal but only the "changeset"...

This plan works for me. Abs doesn't need the patch information necessarily so the full metadata is also fine.

Thanks for working on this!