https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    Yes, that's the simple part of it.
  • b
    Complex were things like you changing a row, then someone deleting it, then both you and him undoing it.
  • b
    Honestly, I've spent over a month just designing how it should work. And since then I've thought back as to why it ended up being so difficult, and I don't know.
  • b
    The main issue came from requirement that editing needs to affect local copy immediately.
  • b
    So the client waited on confirmation for changes, but meanwhile there might come other changes.
  • b
    yeah, defo sounds like alot of edge cases there for sure
  • b
    So you have local copy X -> A_X. Some other user has local copy X -> B_X. Server receives both, and doesn't have an issue with it, last edit holds. But the clients are problematic.
  • b
    Say B was last. A will receive confirmation, then B_X value. Alright. For B it's the opposite order.
  • b
    Now if B, or A press undo, different things need to happen. Namely B needs to revert to A_X, not X. Even though it didn't know about A_X when it did the change.
  • b
    And the undoes and stuff are also instant "client local", so I can't just let server deal with it.
  • b
    I need to know that if a change came in, and before confirmation, I need to edit my undo-redo queue.
  • b
    yeah, the undo is defo problematic there
  • b
    And iirc this was a simple problem to solve. There were some pretty complex edge cases where clients ended up with different local state. But for the life of me I can't remember what they were. Even though I have like 20 pages of design notes. 😄
  • b
    I think I could do a much better job at it now. Would probably rather do a deep dive into Operational Transformation algorithm.
  • b
    But mainly currently backups are pretty hacked in. DB is SQLite, I'm replicating it via SymmetricDB, which is a pain in itself.
  • b
    Setup and installation was a bit ugly. And now they have some security concerns and would like a few changes, none of which are easy with how it is now.
  • b
    Changing to some web based UI (with possibility of native clients being super sweet), DB being proper one with better realtime backup system. Stuff like that...
  • b
    well, all sounds pretty interesting - and complex - im esp. interested in the client sync issue - love stuff like that 😄
  • b
    I have notes about 3 different approaches, but I never marked down what edge cases they were.
  • b
    I just know it was all super simple "last edit stays", until I started thinking about undo.
  • b
    Server was simple enough, no concurrency there. But clients, meh...
  • b
    it sounds like its the undo that screws things... if A undoes their changes, what do you undo to? B's change? Or the data before A made a change?
  • b
    Exactly. It all depended on local state, which was unknown to other clients.
  • b
    arguably the correct thing to do is to undo to B's change... but that will look strange to A
  • b
    Which is the core issue, doing something that depends on something only you have, in a way that results in the same result for everyone.
  • b
    A adds a row. B edits it. A removes it, then undoes that.
  • b
    yeah... can of worms there
  • b
    That's what server receives, but think of all the possible states the local clients can be, depending on the ordering of messages coming from server. Any client might lag for a while, can't depend on the order at all.
  • b
    indeed
  • b
    I remember I ended up writing test suite that did some basic operations and then tested all permutations of confirmation message order.
1...136137138...1687Latest