| daniel added a comment. |
The proposed structure looks good to me. Documentation should make clear that the fields in the structure correspond to usage aspects, and are thus independent of Entity structure.
Note that we have to make sure that we have enough information on the client side to not only determine affected pages, but to also generate the appropriate edit summary (yes, in some cases, we look at the diff to generate a summary on the client side).
Also note that the client will currently re-calculate the diff when coalescing consecutive changes. With the new structure, it should be a lot easier to simply merge the diffs. That should be a significant performance gain for the case of coalesced changes. Not sure how much impact that has overall.
It's not clear to me why both representations of the diff should be present in the object if we only include one in the serialization. How would that even work with deserialization? The deserialized version would then have only one diff representation anyway. It seems to me we want to only include the kind of diff that we later want to actually use. Am I missing something?
Cc: PokestarFan, hoo, gerritbot, aude, Aklapper, daniel, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
