Trying to list the changes and fixes we want to do for the next API release
Public API changes:
- remove support of
string (which is implicetely encoded as UTF8) for the data member in private frame
- align frame types between read and write (make read and write isomorphic)
- separate buffer and file operations
noRaw option should also apply for tags Chapters and TOCs (should be recursive)Promises should only work with files, there is no point having an asynchronous API for Buffers since there are synchronous operations- align all tag aliases names (and terminology) with the ID3 documentation (some tag aliases use a different terminology)
- enable all multiple frames
- unsynchronised lyrics (
USLT)
- attached picture (
APIC)
- others?
- support image file links in
APIC frame
- remove the update function, there are edge-cases especially with multiple frames we can't deal with the function correctly, read and write should enough and more flexible
- read will return an object with
frames (known frames), unknownFrames (with a buffer for each frame) and undecodableFrames, write will consume the same object (unknownFrames and undecodableFrames could be merged in a single undecodableFrames where the reason for un-decodable could be either unknown or an error)
- define a format for
unknownFrames and undecodableFrames
undecodableFrames should have extra information which indicate the failure- should the read function provide extra frame information from the frame header? (frame id, size, etc.) or
- should we provide a utility function to extract information from a frame header (I would say yes)
- have some thoughts of how to deal with identifiers and aliases (remove aliases???)
- write will only accepts identifiers and we provide a converter to convert from aliases to identifiers
- read will only return identifiers and we provide a converter to convert from identifiers to aliases
- this is flexible, robust, composable and simpler
- try to make
zlib and fs dependencies run-time and injectable dependencies to improve portability
- maybe provide a write option to choose the string encoding scheme
Possible future public API improvements:
- provide the ability to write custom frame handlers
Internal changes:
- add an option to
FrameBuilder to emit an encoding byte
- name "at least"
size parameter in FrameBuilder and FrameReader as very often this is a static value
- rename
FRAME_OPTIONS to FRAME_PROPERTIES I think this is more appropriate
Related issues:
Trying to list the changes and fixes we want to do for the next API release
Public API changes:
string(which is implicetely encoded as UTF8) for thedatamember inprivateframenoRawoption should also apply for tags Chapters and TOCs (should be recursive)Promisesshould only work with files, there is no point having an asynchronous API for Buffers since there are synchronous operationsUSLT)APIC)APICframeframes(known frames),unknownFrames(with a buffer for each frame) andundecodableFrames, write will consume the same object (unknownFramesandundecodableFramescould be merged in a singleundecodableFrameswhere the reason for un-decodable could be eitherunknownor an error)unknownFramesandundecodableFramesundecodableFramesshould have extra information which indicate the failurezlibandfsdependencies run-time and injectable dependencies to improve portabilityPossible future public API improvements:
Internal changes:
FrameBuilderto emit an encoding bytesizeparameter inFrameBuilderandFrameReaderas very often this is a static valueFRAME_OPTIONStoFRAME_PROPERTIESI think this is more appropriateRelated issues: