@linonetwo Having experimented with Yjs syncing, I also realized that “the files on disk as source of truth” doesn’t really work for a lot of things. I have moved to thinking of the Files-on-Disk as a “rendered Tiddlywiki, like the HTML+DOM in a browser”, so if you change a file on disk and run a command to pick that up, that would be equivalent of opening a tiddler in edit mode and saving.
1 Like
Thank you for this inspiring upgrade!!!
This is expanding TW so much that it really is shaking what I thought is possible on the server-side.
- Does this mean, a wiki a client uses would be updated, if a tiddler is changed in the MasterWiki?
- Is there a strategy to resolve conflicts if two users edit the same wiki?
- Is there a history and a mechanism to roll back mistakes
- Will there always be a secure way back to a singlefile-wiki?
- Will the ughlify-mechanism be able to work within this setup?
- How do users access a wiki dedicated to let’s say history if there a more wikis hosted in this server?
1 Like
Yes indeed. There is a tension between the needs of the boot process and those of the sync process. Decoupling them makes MWS much simpler to work with.
Yes. As far as the database is concerned, the sync process is just an API client, using either the JS API or the HTTP API.
Yes. Changes are already sent from the browser to the server almost instantaneously, but the reverse process for getting changes from the server to a client currently relies on polling, which is inefficient and slow.
There is some conflict detection, but I don’t have plans to address conflict resolution within this work.
The conflict detection just means that users will be notified if they attempt to modify a tiddler that has been edited by another user since the copy of the tiddler that the first user modified. We’ve never handled that situation well, but I hope to be able to at the very least put the tiddler back into draft mode and invite the user to edit it. (I also want to explore changing the “done” button when you’ve finished editing a tiddler so that it waits until the tiddler has been committed by the server before switching out of draft mode).
Yes, I do hope to offer tiddler history as an option.
There will be two ways:
- Visit an interactive wiki and use an export option to download a snapshot of the wiki
- Directly visit a URL that will give a JSON backup of the content of a wiki
There’s no reason I can see why it wouldn’t work.
Do you mean tiddler history?
It is likely that in the first instance the only UI for tiddler revisions will be to be able to open a static page that shows all the earlier revisions, with the ability to download one as a JSON file. We can build on that to be able to offer more sophisticated UI features.
1 Like
Thank you for the replies @jeremyruston,
History and Arts are my subjects at school. So how would users adress the different wikis if they are hosted on the same multiwiki-server?
I just want to say this is all very exciting.
I don’t currently do anything with TW that warrants it but occasionally think about how I would use TW for a shared Wiki and the only solution I was aware of is the Bob Saver. We’ve been considering (for far too long now) how to share our scribblings at the local computing museum I volunteer at where I think it may go to OneNote as it’s already been paid for and ease of use but I’ll definitely keep TW as a backup plan for when ON screws up.
Correction: Sharepoint was mentioned too but somehow it moved to OneNote.
2 Likes
I totally agree, but don’t ignore the idea of serial editors. If everyone can read and write a wiki, but you place layer that flags the wiki is “checked out” by someone else and unavailable to edit until “checked in” it is a reasonable work around until we have better.
- This works particularly well on top of another document management tools such as SharePoint where only one person can checkout the document anyway.
Never the less, I expect tiddlywikis use, to explode with a well developed and supported multi-user set up, by wiki or tiddler. Especially if secure on the internet, not just in a trusted environment like an intranet.
- [post script] especially if its publishing on the internet is not too complex.
If it’s the best we can do, I would live with that. But I’ve had some really bad experiences with that model, and was so glad when developer tooling moved beyond it.
There’s a whole generation of software developers who still do an involuntary shudder if you say “Visual SourceSafe” aloud.
I am not sure what this means, but the solution outside of SharePoint I have, leaves very little room for editors to end up in contention. In SharePoint its very secure.
- I implemented the serial editing SharePoint solution in a business, they had two editors + me, who worked together and never had a problem.
One simple approach would be to have a “history” bag and an “arts” bag. You could then expose them via different recipes:
- a view of just the history bag
- a view of just the arts bag
- a combined view of both bags
A lot depends on whether you want to be able to interlink tiddlers between the two subjects, which would suggest focusing on the combined view. Or your usage may be more similar to mine, where the only shared element between my different wikis is a small number of customisations that I like.
------ slightly OT
Oh – That makes me feel old – “Visual SourceSafe” was a Microsoft source control system using a file locking mechanism. A common pattern was, that someone checked out a directory tree and then left for a 2 weeks vacation.
/OT
2 Likes
Hi @jms19 it may be too late to be useful, but apparently TiddlyWiki out of the box can save changes to a SharePoint drive. Judging by an earlier post, @TW_Tones might have useful comments.
It might perhaps allow you to create TiddlyWiki’s that you can share with others in the organisation, without them having to step outside of the authenticated environment of SharePoint.
To pick up the comments about conflict resolution, the current expectation is that MWS will only provide explicit support for the lowest level of conflict detection. In particular, it should be impossible to overwrite a modification of a tiddler made by someone else without being aware of it.
In more detail, the wiki in the browser knows the last revision number of the tiddler that was known to be on the server. When it sends a request to change a tiddler to the server, the code in the browser also provides what it thinks to be the last revision number of the tiddler in question. If the tiddler actually has a different revision number because it has been modified in the interim by another user, then the server sends back an error.
There are a lot of different ways that we could expose that basic functionality in the user interface which we will have to explore in due course.
Beyond that, there is the general philosophy of tiddlers that suggests making tiddlers be the smallest possible units. One of the benefits of that approach is that it minimises the chances of two authors wanting to edit the same tiddler at the same time.
In situations where features like the ability to lock a tiddler are required, I am hoping that they can be implemented within the UI. For example, given the tiddler title, the view template could look for a configuration tiddler to decide whether or not to present the editing features. Implementing these mechanisms at that layer (rather than in JavaScript) should allow anyone in the community to experiment with different ways of balancing the requirements of these kinds of situations.
3 Likes
Jeremy this is great.
To support innovation at this level perhaps we can expose a little information from MWS such as the ability to query the tiddlers version on the server?
- the idea would be while developing MWS provide primitive functions to query critical information not available any other way for later innovation.
Perhaps later we could introduce a mechanisium to request a change knowing it may be rejected and have a programmatic way to respond to the message returned rather than forcing it into the user interface.
- perhaps we could even return the tiddler we would overwrite for sophisticated responces such as identifying who made the change and when, the differences etc…
- this kind of information could help reduce the number of tiddler in contention
I wonder which is the best approach on how to migrate a nodejs folder wiki to a multiwikiserver wiki.
I suspect that is just feeding all .tid files into the SqLite database, so probably a python script?
Sure there are many ways to do that, anyone has walked this path already?
1 Like
There is a --mws-load-tiddlers <path> <bagname> command that loads all the tiddler files from a given folder into a specified bag.
1 Like
This looks great!! Are there instructions somewhere on how to get started? Thank you in advance!
Thank you @anthrospeak.
MWS is still at a relatively early point in its development, and is best treated as a prototype for the moment. At the moment it lacks many important features (such as authentication) that would be needed for production use. But, if you’re comfortable with that it is a great time to evaluate MWS and influence its future direction.
I haven’t written up friendly instructions yet, but the installation procedure is to download the ZIP of the repo, and then in a terminal window in the root of the repo run npm install to install dependencies, and then npm start to start the server. The server will print the URL that you then visit in your browser.
Hi Jeremy,
can you say apporiximately when we will get a release reliable enough for production ?
1 Like