Announcing the MultiWikiServer Plugin

#30

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.
#31

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.

1 Like
#32

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.
#33

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.

#34

------ 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
#35

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.

#36

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
#37

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
#38

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
#39

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
#40

This looks great!! Are there instructions somewhere on how to get started? Thank you in advance!

#41

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.

#42

Hi Jeremy,
can you say apporiximately when we will get a release reliable enough for production ?

1 Like
#43

Hi @JanJo I’m hoping MWS will be released before TiddlyWiki’s anniversary in September.

4 Likes
#44

Just to confirm, to install the prototype we need to run this command in the folder of our choice, right ?

git clone -b multi-wiki-support https://github.com/Jermolene/TiddlyWiki5.git
#45

This did it for me:

git clone https://github.com/Jermolene/TiddlyWiki5.git --branch multi-wiki-support

cd TiddlyWiki5

npm install

node ./tiddlywiki.js ./editions/multiwikiserver --listen
3 Likes
#46

Thank you @telumire and @LoryMoney. I’ve updated the plugin docs to improve the installation instructions, and also updated the readme for the branch (see GitHub - Jermolene/TiddlyWiki5 at multi-wiki-support).

1 Like
#47

@jeremyruston

Server-side, are there plans to fire events for updates to tiddlers in bags - such as updating a ‘$:/event/MultiWikiServer’ in $tw.wiki when a user updates a tiddler in a bag - thus would get a ‘change’ event to signal the database has changed?

Or is it already implemented and I am Missing it?

#48

Not exactly. The way that MWS works is that the “tiddlers” table has an ID field that is automatically incremented on each change. (See the SQLite docs for details).

This allows us to easily query the database to obtain a list of all tiddlers that have changed since a given previous change.

So, the equivalent of a change event listener is a periodic process that queries the database for the ID of the last change, and compares it with the last change that it knows about.

Not everything I have described is implemented yet – notably, deletions are not yet represented in the “tiddlers” table.

This will be the basis of a new, instantaneous synchronisation mechanism based on Server Sent Events.

As an aside, over the last few weeks I’ve been working on multipart form upload. This allows a browser form to upload huge files efficiently. On the server side, the incoming files are streamed to the file system and then turned into tiddler attachments, without ever being entirely stored in memory.

As things stand, bags and recipes are mirrored to $tw.wiki and so it would be possible to listen to change events on that wiki to learn of the creation of bags and recipes. But there are no plans to update the admin wiki for every updated tiddler, so change stamps would have to be used to track tiddler changes.

1 Like
#49

Hello, thanks for this interesting evolution of Tiddlywiki. I am not a developer but I started using Tiddlywiki more then 6 years ago, now, even for some specific task concerning my job.
I make use of some well known plugin, such as TiddlyMap and GSD5.
I succeeded to install and run the MultiWikiServer version and the system write perfectly in the SQLite file. I am planning to use this version for prototyping in my projets needing some data classification and visual analysis.
When I try to use those plugins with the recipes and bags, I am not able to upload them. Installing them by the plugin directory in the wiki datafolder or/and by adding lines in the tiddlywiki.info, does not work.
Could you suggest me what I am missing and how I can integrate plugins in the bags, please?