reduce number of terms, helper functions and make docs and variable naming consistent #7

hpk commented 2024年02月11日 19:44:46 +01:00

with webxdc there is no chance of "non-confirming" updates.
current guarantee is that an app will always see exactly what it is sending, there are never "old" clients or compatibility issues. But i wouldn't explain that here, and simply do no validation whatsoever.

with webxdc there is no chance of "non-confirming" updates. current guarantee is that an app will always see exactly what it is sending, there are never "old" clients or compatibility issues. But i wouldn't explain that here, and simply do no validation whatsoever.

ansuz commented 2024年02月14日 07:19:46 +01:00

I initially added the validation while I was working on my PR because updates sent from an earlier version of the app (testing with webxdc-dev) produced some weird results. I think it was something with the greatest timestamp being set to a weird value early on, with subsequent addition and Math.max operations producing NaN somehow, and that being serialized as null in the update.

Restarting webxdc-dev entirely wiped the history so only updates from the new client version were loaded, but having that type check there made it such that any temporary tweaks while prototyping/refactoring would not put it back into a bad state. I figured that anyone looking to fork the app and add new features might run into something similar, so I left it in.

Aside from that, the overhead is negligible and has the benefit of protecting against malicious/mischevous behaviour in case anyone wants to embed the app in a platform with slightly different guarantees or social context (like a web platform with people who trust each other somewhat less than a friendly chat group).

I don't feel strongly about keeping either the validation or the comment, as I agree that the complexity may be more than a beginning developer is able to process. I just want to provide some of the context behind its inclusion.

I initially added the validation while I was working on my PR because updates sent from an earlier version of the app (testing with `webxdc-dev`) produced some weird results. I think it was something with the greatest timestamp being set to a weird value early on, with subsequent addition and `Math.max` operations producing `NaN` somehow, and that being serialized as `null` in the update. Restarting `webxdc-dev` entirely wiped the history so only updates from the new client version were loaded, but having that type check there made it such that any temporary tweaks while prototyping/refactoring would not put it back into a bad state. I figured that anyone looking to fork the app and add new features might run into something similar, so I left it in. Aside from that, the overhead is negligible and has the benefit of protecting against malicious/mischevous behaviour in case anyone wants to embed the app in a platform with slightly different guarantees or social context (like a web platform with people who trust each other somewhat less than a friendly chat group). I don't feel strongly about keeping either the validation or the comment, as I agree that the complexity may be more than a beginning developer is able to process. I just want to provide some of the context behind its inclusion.

hpk commented 2024年02月11日 19:45:57 +01:00

think it's not worth an indirection via a setPixel function.

think it's not worth an indirection via a `setPixel` function.