You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Full words create needless storage or network traffic, if I had to send thousands of patches through a network connection, or store millions of them in a database I'm wasting allot of bytes needlessly.
So having the ability to have shortened operators and keys would be beneficial something like:
replace = rp
remove = rm
copy = cp
move = mv
I agree, this should not be part of the spec. Both network traffic and database values could be compressed (e.g. HTTP Accept-Encoding: gzip, deflate) which would compress your data even more than that!
Yes, such optimizations are at the wrong layer. No need to complicate the patch format to optimize here. Because it is not just about keys, but also about values, they can also be duplicated many times. Compression solves all those problems at once. Many transport formats and databases support compression.
Activity
ctranxuan commentedon Sep 14, 2015
👍
sonnyp commentedon Sep 14, 2015
I don't think we need to add this to the spec.
Nothing prevents you from using your own serializer/parser see https://github.com/JSON8/patch#patch-size
Also for millions of items you'd probably go with some + efficient binary format
heruan commentedon Nov 3, 2016
I agree, this should not be part of the spec. Both network traffic and database values could be compressed (e.g. HTTP
Accept-Encoding: gzip, deflate) which would compress your data even more than that!mitar commentedon Oct 12, 2019
Yes, such optimizations are at the wrong layer. No need to complicate the patch format to optimize here. Because it is not just about keys, but also about values, they can also be duplicated many times. Compression solves all those problems at once. Many transport formats and databases support compression.