Comments (3)
That`s a good point. I'll see what I can do here.
from tone.
@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"...
from tone.
@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!
from tone.
Related Issues (20)
- a feature request for batch tagging HOT 10
- Could not find file with double quote in name and folder HOT 3
- Unable to remove movement tag with --meta-remove-property HOT 3
- Enhancement - Allow to set only year for all date properties
- --meta-subtitle is not written if file does contain any metadata HOT 2
- tone tag use too much ram HOT 3
- When auto importing covers, every file gets the same cover image HOT 5
- How to identify CTOC (Table of Contents) chaps from mp3 HOT 5
- Incorrect Next track ID after import chapters HOT 5
- Not real issue, only works with block storage HOT 2
- Some value of returned JSON are malformed HOT 4
- Embedded Picture MimeType... HOT 2
- Embedded Picture Cover Type... HOT 1
- Embedded Picture Invalid ID3 frame size.. HOT 3
- Feature Request: perfect opus merging without 'click' HOT 1
- Tone tagging takes a long time for some files HOT 17
- Tone corrupts some m4b files, rendering them unable to play in ABS HOT 11
- Issue when enhancing `musicbrainz.js` script to incorporate chapters HOT 2
- Feature Request: Import chapter from CUE Sheet HOT 5
- tone v0.1.7 reports version 0.1.6 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tone.