7 ms·

regarding the architecture: basically is (or is very much like) event sourcing, right? I mean, kind of like an append-only log, that will grow forever.

TheTon 11y ago
(author here) Yes, that's right, at least at the source of truth on the server. Clients automatically rewrite or squash their local history a little bit prior to pushing it to the server to minimize log length and to avoid showing intermediate editing states that were never communicated to anyone else (just like you might squash git commits), but every important state is preserved in the log.
- foo123456 11y ago
  ok tnx! as a dev myself, i'm still not convinced about this whole append-only/time-machine approach (i'm talking more about event sourcing in general, not your specific architecture). it smells too much architecture astronaut (see http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html and http://www.joelonsoftware.com/items/2008/05/01.html http://www.joelonsoftware.com/items/2008/05/01.html). it feels like this incredibly heavy monster system that theoretically may let you do anything, but in practice, at the end of the day, is not able to do it because it is impractical to use. again, not necessarily yours.
  - mbrock 11y ago
    Git itself is exactly such an append-only system, and it's one of the most reliable and useful tools ever. What's the problem?
- alkonaut 11y ago
  > Yes, that's right, at least at the source of truth on the server. I assume the server holds human-readable issue id's, but clients do not then (until they are pushed to the server). Do you assign just random guids to issues on the clients and then issue running issue numbers to them once they are on the server? If so, if I enter two issues on the client side with a reference from one to the other, how do I enter the cross-reference before I have the (server issued) issue id for either issue?

TheTon 11y ago

(author here) Yes, that's right, at least at the source of truth on the server. Clients automatically rewrite or squash their local history a little bit prior to pushing it to the server to minimize log length and to avoid showing intermediate editing states that were never communicated to anyone else (just like you might squash git commits), but every important state is preserved in the log.

foo123456 11y ago
ok tnx! as a dev myself, i'm still not convinced about this whole append-only/time-machine approach (i'm talking more about event sourcing in general, not your specific architecture). it smells too much architecture astronaut (see http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html and http://www.joelonsoftware.com/items/2008/05/01.html http://www.joelonsoftware.com/items/2008/05/01.html). it feels like this incredibly heavy monster system that theoretically may let you do anything, but in practice, at the end of the day, is not able to do it because it is impractical to use. again, not necessarily yours.
- mbrock 11y ago
  Git itself is exactly such an append-only system, and it's one of the most reliable and useful tools ever. What's the problem?
alkonaut 11y ago
> Yes, that's right, at least at the source of truth on the server. I assume the server holds human-readable issue id's, but clients do not then (until they are pushed to the server). Do you assign just random guids to issues on the clients and then issue running issue numbers to them once they are on the server? If so, if I enter two issues on the client side with a reference from one to the other, how do I enter the cross-reference before I have the (server issued) issue id for either issue?