Ways to compress url search query for animation (repeated state complex json object)

[jo-chemla]

Context: I'm building terrain-viewer, and storing a pretty large state (visualization modes, opacities, parameters for multiple layers of terrain hillshade, color-relief, contours etc) so users can share the exact same visualization via url in a pure client-side app.
Just opened an unrelated feature idea related to parseAsColor here #1342

I'm doing simple pose interpolation animations, and am anticipating the moment when I'll want to store in url query-param the whole, or portion, of that state at different (at least 2) animation keyframes, snapshot at a given timestamp/keyframe. I'd love to compress the state as much as possible, so url do not become too long.

Some possible ideas I would love to get some help and discuss which would be best:

• I would love to reuse the shorter search-param keys urlKeys, but for a children object of state. Maybe use simply 1-2 chars shorter name, but apply it to a json object like pose1, pose2. Could result in a url search query like this ?latitude=10&longitude=10&pose1={lat:11,lng:11}&pose2={lat:12,lng:13}
• Note the development is still ongoing and I'm not already sure of the upcoming state variables there will be, hence I think I cannot encode in a given ordering, or use alphabetical ordering, to avoid encoding the state keys and "just" encode the state vlaues
• eventually storing numeric values as float/double 2-4 bytes ascii encoded rather than string with decimals? not necessarily a large benefit, Float32 are 4 bytes and can be base64 encoded to 6 characters (trimming padding), or fixed point integer scaling to 4 bytes if known precision/required decimals
• but maybe I'm using the wrong perspective, and what would actually be best is storing deltas between current state, pose1 and pose2. For example, if no pose have been set yet, when the user sets pose1, it stores the full state, but when the user edits some state values, and chose to remember pose2, at this time only deltas should be stored within pose1 and pose2, since the full, static, state are already stored in state and url. If there is a way to do this, it seems like this would be the most compact state representation within url.

Hope this all makes sense! I realize it is a pretty narrow use-case, but would love to hear your thoughts around compact state representation for such cases!

[franky47]

Taking your points one by one:

I would love to reuse the shorter search-param keys urlKeys, but for a children object of state. Maybe use simply 1-2 chars shorter name, but apply it to a json object like pose1, pose2. Could result in a url search query like this ?latitude=10&longitude=10&pose1={lat:11,lng:11}&pose2={lat:12,lng:13}

Try and keep the state as flat as possible. Maybe something like ?lat=10&lng=10&p1lat=11&p1lng=11&p2lat=12&p2lng=13. If the two poses have the same structure, that could help use the same descriptor object, but use dynamic urlKeys to prefix in the pose number.

I think I cannot encode in a given ordering, or use alphabetical ordering, to avoid encoding the state keys and "just" encode the state vlaues

Always assume the search params are in an arbitrary order. It's an unordered key-value store under users' control.

eventually storing numeric values as float/double 2-4 bytes ascii encoded rather than string with decimals? not necessarily a large benefit, Float32 are 4 bytes and can be base64 encoded to 6 characters (trimming padding), or fixed point integer scaling to 4 bytes if known precision/required decimals

For ASCII, you'll likely end up with url-encoded values if out of the safe character set, so not worth it imho. base64url is a safer bet.

but maybe I'm using the wrong perspective, and what would actually be best is storing deltas between current state, pose1 and pose2. For example, if no pose have been set yet, when the user sets pose1, it stores the full state, but when the user edits some state values, and chose to remember pose2, at this time only deltas should be stored within pose1 and pose2, since the full, static, state are already stored in state and url. If there is a way to do this, it seems like this would be the most compact state representation within url.

Definitely, and another way to reduce the amount of state stored is to avoid storing anything that can be computed or inferred from other data.

Another thing I see from your state descriptor object is a lot of parseAsBoolean, you could save a lot of space by packing those into a bitfield for the showXYZ properties (as long as you guarantee the order remains the same for the lifetime of the app).