Hi y'all, Thanks for these really good ideas and insights, here's a wall of text dumping some of my thoughts :)
TonyM, I agree that the most important first use case is having a simple one-file one-user one-device way of saving. There are many solutions to this already, though it seems like most still require _some_ configuration. I think as a first time user (not aware of quines, browser extensions or servers) I would first just look for a desktop version, which could be an electron app that would mostly just wrap the nodejs server and present a client that connects to it. Alternatively it could also just wrap the html quine and handle saving of the html file. If I understand your original use-case of a team of people sharing multiple documents amongst each other, it's more of a multi-file multi-user setup. I think having a central nodejs server there is probably the simplest solution if there is one person that can manage it. I'm not sure how you could have a check-in/check-out workflow in the context of passing wiki document files around i.e. how does my pc know that you opened a document and checked it out on your pc? You'd need a central server or some other way to transfer this state. In which case you could just use the nodejs server to host the wiki in the first place. If you don't have this check-out state synchronized, you end up having multiple people edit the same wiki/fle, having to merge them after the fact. In the context of having check-in/check-out as part of a central server, it's probably the easiest way to solve the multi-user editing scenario. For me personally that would bring a lot of friction and manual synchronization within the team (who checks out/in what and when?). This is also similar to non-distributed version control systems like Perforce, where this is often used for files that are hard to merge (media assets, etc.), so it's a necessary evil, so to say. Anyway, the crux of the matter for multi-user wikis is really synchronization and merging between several sources which change over time. This is clearly a complex problem, but I believe it has been essentially solved by Operational Transforms (Wikipedia <https://en.wikipedia.org/wiki/Operational_transformation>, OT Explained <https://operational-transformation.github.io/>). This is essentially how Google Docs and similar have been doing collaborative editing with no check-in/check-out and no manual merging. This doesn't necessarily make it simple to implement, but I believe it's the way to go for server-hosted TW on nodejs. Ilya, That's an interesting setup. So essentially it's a phone-first wiki with everything hosted on the phone and then you just access it from your PC when you need to. Sounds like an extreme way to solve the offline problem, but it's probably the best way right now :) As a first step, saving changes to localStorage would be a good idea in combination with a server. This is independent of having a desktop app, since it would benefit both. Service discovery is probably only relevant from the point of view of an app, something like DNS-SD <https://en.wikipedia.org/wiki/Zero-configuration_networking#DNS-based_service_discovery> could be used. The end goal for conflict resolution is probably Operational Transforms as described above. In the mean time a 3-way diff view (base, mine, yours) with an edit box where you merge the result manually might be the easiest to add. Recent TW versions already have diff-text <https://tiddlywiki.com/static/DiffTextWidget.html> functionality, so it's mostly a matter of plumbing. Compare different historical versions & snapshot of the wiki: I've experimented with implementing the former with a plugin and service to access git file history and present it in the UI directly and I think it's a good way to go. The snapshot is also easy to achieve by checking out a different git commit as you said already (presenting this in the TW UI might be a bit tricky, as the whole state of the wiki would change under you). I agree that some sort of a sync and sync status indicator is needed. For the implementation, I would try to reduce the complexity and number of moving parts as much as possible. So I wouldn't change any core TW mechanics in the first versions as they aren't really required, because git already tracks changes in files and renames as well. Having an actual ID for a tiddler might be a good idea at some point though. I don't see the added value in having a separate saver for this as the file-based saver and the REST API that's already there is good enough for maintaining the current state. For historical versions, I've experimented with having a Go service that just serves git file history and the proof of concept seemed to work well, now that I think about it, an even better way to go would be to just have it as a server-side plugin for the nodejs version of TW. Arlen, I've actually tried TiddlyServer first and it seemed neat for serving multiple wikis. I stuck with vanilla though, as you mentioned if you don't have a use for multiple wikis, most of the functionality is in the TW core now. I think having the wikis in a Dropbox folder is definitely one of the best ways to have a backed up versioned wiki. I think integrating git would be a good way to expand on that functionality and for better integration. Clearly a lot more effort required on that front though. I like that since Dropbox is also available on mobile, you could probably hack together a solution that used that sync too. But it would be more of a hack than anything I guess. Sorry if I exceeded someone's bandwidth cap with the brain dump above, but I didn't have time to make it shorter ;) Best, Miha On Sunday, November 24, 2019 at 4:23:05 AM UTC+1, TonyM wrote: > > Arlen > > Thanks for sharing your use of tiddlyserver which I also use a lot. All my > tiddlywiki file locations are in my ts index. I have a wiki I open for > generating wikis using the the big green button to save into a folder that > I then browse with ts. > > This keeps maintaining an index to wikis very easy. I also use it along > side timimi and sometimes bob and tiddlydesktop. > > It would be nice to preconfigure tiddlyserver to a standard setup and zip > it into a executable zip file to ease its deployment. Is there a minimal > configuration we can use? It would also be nice if we could add paths ports > and addresses to the setup file via a tiddlywiki, reducing the errors. > Generating the settings file rather than a copy of a text file. > > Love your work > Tony > > -- 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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c3851269-353d-4481-87e3-1d042f733a65%40googlegroups.com.
