Support JSON response when tagging
advplyr opened this issue · 3 comments
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.
That`s a good point. I'll see what I can do here.
@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?
- No output at all
- Full output
- Would you expect the full metadata information result after tagging or only patch information?
- Full metadata information would contain everything that can be read from the file
- Patch information would only contain changed properties (see https://github.com/wbish/jsondiffpatch.net#patch)
- What would you expect on errors besides return code different from 0? (e.g. file cannot be updated, disk full, etc.)
- No output at all
- No output on stdout, error message on stderr
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"...
@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!