Interesting - I greatly appreciate the input/detail @pmario! In many (though not all) of my intended use cases, restricting others to *only add* operations (no changes) via UI trickery would be doable. My use-cases usually involve *me* setting something up a list of business decisions for review, and have others comment / approve / rate etc, which I'd usually store in the background as system tiddlers incorporating user names. In such a worflow the "conflicts" are not a real issue, and I can even handle the timing lag of it being propogated to others in most cases, though reducing that would be ideal.
I start node each morning and it gives me the standard Serving on http://127.0.0.1:8080 message, so I'd have to figure out how to get that to a 10.1.X.X situation for LAN usage to multi-serve right? In BOB there's some buttons to press, so the actual method of how to do this in base-node is something I'm not aware of. On Wednesday, August 18, 2021 at 8:12:07 AM UTC-4 PMario wrote: > Followup, > > On Wednesday, August 18, 2021 at 2:03:53 PM UTC+2 PMario wrote: > ... > >> The function is called "syncFromServer". So if you open 1 wiki in 2 tabs >> of a browser you will informed, if someone opened a tiddler. A _red_ "draft >> of ... by <name>" button will be shown in the bottom of the wiki window. >> The name will be only there if the username is set in the ConfigTiddler! >> > > The server sent event plugin triggers the exact same mechanism. So it's > possible to create instant feedback without the need to modify core > functions. > The disadvantage here is, that there is quite some overhead over the wire. > The message flow is like this: > > 1) Server informs the client about new data > 2) Client reads all the tiddler meta-data without the text field > 3) Client compares all titles to see if something changed. > 4) If something changed the client reads ALL tiddlers including text > content > 5) Client saves new data > 6) TW UI shows new data. > > This workflow is OK for the current client implementation, since it runs > on a client-side timer. But the with SSE it could be like this: > > - 1) Server sends the changed data to the client > - 2) Client saves them > 3) TW UI shows new data > > As you can see, there is a lot of room for improvements. Especially the > "Conflict Free Replicated Datatype" that Joshua mentioned would be an > interesting option here. > > -mario > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b4699eb3-2ccc-4021-b266-157b20b40bd5n%40googlegroups.com.
