Does this mean that I would need to be running node.js in order to take advantage of these changes? Or might it be possible (at least in theory, eventually) for a server-based solution like TiddlyHost to offer complex bags-and-recipes MultiWikiServer-style accounts for users who access TiddlyWiki on web-based connections?
I see that this is an elegant default for interface-specific changes that should stay “shallow” to any given wiki, or for laying the groundwork for multi-user permission structures where write-access to “deeper” bags can be restricted…
Like @srbt1 I expect it would be very helpful (at least in a single-author world) to be able to save “back to the source” under certain conditions. For example, when I realize I need to fix an error in a definition-tiddler, that’s the kind of edit that I’d always want to lock in back at the “bag of definitions” shared across many projects, without having to shift to another wiki interface to make that edit. Of course, a frequent maintenance-routine of scanning my top-level bags for tiddlers that fit various conditions (such as being tagged “definition”) could ensure things end up where they belong. Still, I could imagine various workflow hiccups that would result from making it impossible, from within any given wiki interface, to save directly to bags other than the topmost.
I’m aware how long this has been in development, and am chuffed to see this announcement!
Hi @john.edw_gmail.com the plan is to maintain the same support for lazily loaded tiddlers as we have today, but with some modest improvements (for example, I would like to avoid having to expose the _is_skinny field that we currently use to mark a skinny tiddler that has not yet been loaded, and instead offer an is[skinny] filter).
I did experiment with early versions of Xememex working in that way, but we found that it was confusing for users because it means that you cannot predict the bag to which a tiddler will be saved unless you know the bag that it came from. In contrast, with the present arrangement tiddlers are always consistently saved to the same bag within a recipe. That means that you can look at the address bar of the browser and know where your changes will be saved, which only requires familiarity with the recipe, and doesn’t require inspection of a specific tiddler to see where it is saved to.
With a shared system, inadvertently saving something into the wrong bag might have implications for the privacy of data (for example, imagine a teacher sending a note intended for a specific student but having it visible to the entire class). So we want to be conservative, and minimise the chance of surprise.
Having said all of that, I would like to expose the logic that chooses the bag to use to save a tiddler so that it is hackable, and users can experiment with other configurations.
To take advantage of these changes does indeed mean that either you would have to be running node.js, or you could use a hosted version that was running on a server operated by someone else.
I think it is still highly beneficial to have the option of both ways of working. Nothing here will make TiddlyHost any less useful.
It is very tricky to get these semantics right. It is easy to make the rules complex, but the cost is that the user has to run the algorithm in their head every time they save a tiddler.
My hope is that we can make the rules for saving to a recipe cascade be brutally simple, and compensate for any loss of flexibility by providing good tooling for moving tiddlers between bags.
The workflow processing that I referred to above might also be relevant. In essence, this is the ability to perform server-side actions when a condition is met. For example, one might have a very simple workflow that looked for tiddlers in one bag that met a certain criteria and automatically move them to another bag.
Multiple users editing the same wiki has pretty good support with the existing TiddlyWiki on Node.js setup, but if there are shortcomings I would certainly hope to address them.
Hopefully so. It will be satisfying to fill in the gaps and get things working properly.
The core doesn’t split neatly along those lines. For example, if one considers the set of core widgets and tries to separate the ones that are concerned with editing one might choose the <$edit-*> widget for a starting point, but of course it is also used to present the search user interface. There are certainly templates that are only concerned with editing, but they don’t make up much of the bulk of the core.
I have been following your progress on this on Github. It has made me completely re-think how I want to structure the live-multiplayer server. Mahalo (thanks) for starting this thread so we can talk about intent/data-structure/etc I also see the need for a “Publish” UI on a tiddler that could move a copy of it to another bag (and optionally delete the copy in the topmost bag to expose the new tiddler in the lower-bag). That probably needs hashed out more thoroughly, etc. Excited to see where this goes.
Great, thank you @joshuafontany I am glad it is hitting the spot.
I think that sounds like the workflow mechanism I am envisioning. I’ve done a few attempts over the years at state machines modelled as interlinked action tiddlers, and now I’m hoping to tie that work together into a robust mechanism we can use on the server.
A workflow step would have a condition (expressed as a filter) that, when satisfied, would trigger the execution of the associated actions. The available actions would be pretty much what we have today, but we would need to add support for triggers such as:
Elapsed time interval (like cron)
Successful completion of another workflow step
The trickiest aspect seems to be exposing enough of the inner workings interactively to enable users to understand what is going on, and be able to debug when things don’t work as expected. It’s also remarkably easy to set up infinite loops, or thrashing between two opposing actions.
Can we still keep .tid file in some way while use this plugin? Can filesystem-syncadaptor still be used to sync changes from SQLite to fs, so SQLite is just a cache?
Since TidGi is a Tiddlywiki based Obsidian replacement, so I want to keep it .tid/.md files based, like Obsidian.
It will be possible to sync from the tiddler store to an external file directory. But you couldn’t treat the .tid files as the master copy because they would lack the metadata needed for syncing discussed above.
I am sure we will be able to give users lots of options for getting data out of MWS in whatever format they want.
The biggest issue of how the current sync ‘server’ edition is linked into the boot process via boot.files which requires a reboot to load tiddlers updated from external sources.
@jeremyruston Am assuming that if an external source updates tiddlers in the SQLite database they will take effect immediately?
@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.
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.
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 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.
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.
