Check in and out critical to the use of tiddlywiki

[AnthonyMuscio]

Folks,

I have presented this argument many times but have not had much traction. As far as I can see presently the only multi-user update implementation of tiddlywiki is Bob, this is on node and has complexities making it internet facing. Not too mention the support is forced onto only one person.

This is keeping tiddlywiki from being used as a collaborative environment

I was ready to have a rant but decided to put this case, to test if my impressions were correct. The rant may come later.

First please understand I have cultivated a position of superuser/tiddlywiki designer and avoided becoming a developer. You can count on me to be able to overcome almost any barrier (perhaps with help from the forum) but without resort to javascript or development, with the exception of the things I ask of developers, such as in this example.

Check in and out critical to the use of tiddlywiki. Serial editing is the top unmet requirement for TiddlyWiki!
A related issue is allowing strangers to submit content through tiddlywiki, but I will address that another time.

The easiest and simplest answer, which is also applicable to Single file wikis is a mechaisium so users can checkout a document for update and only after check in, can the next person edit it, through a check out. This is called serial editing, it is the poor mans multi-user, its just not multi-access (simultaneous). And yes there may be times when we may loose data by overriding a checkout, however this is unlikely if only trusted users are given access and we can contact them.

If you stop and think about it, be it a shared folder, LAN share, timimi, tw-reciever, a cloud drive etc... we already have the capacity to save the tiddlywiki, and even choose the name of the file to save, this is proof that what I propose is possible. In fact there was even a lock mechaisium in TWC where we could deploy TWC on a LAN drive and avoid contention. Yet this can't be done in TW5?

If I use SharePoint's check in and out facility it works very well, it's only annoying you can't request checkout from within tiddlywiki, like you can with say a word document.

With respect, I don't feel I need to say how we should do this, but we must do it and it is possible.

Just to help if you doubt this consider;

• Separate the right to save to the host, to that from facilitating the actual save to a host, a logical read only
• Simply allowing a lock file to be read/written separately from the save mechaisium.
• Requesting checkout on the URL and on granting save and reload the wiki (as checked out) so no one else can.
• a special tiddlywiki designed to manage the check in and out of multiple tiddlywiki's in the same location, but separate files. Have a secret that if not used the selected wiki will not allow save.
• the worst case would be a checkout mechanism for every save mechaisium (I do not think this necessary)
• Make use of a third party Database to record check-in and out, Ideally provisioned as a service to all tiddlywikis. This could also grant a unique ID through registration on which to base a GUID.
• Allow users to save content to their own file(s), which is loaded along with other users to compile a consolidated tiddlywiki. This can be handled with a user based namespace. this may support //submitting content through tiddlywiki//

Please, please help me break this final barrier.

Tony

[joshuafontany]

I follow your threads, Tony, but am really focused on a Bob upgrade atm. I think while many of your feature request are "hackable", its the combination of them - and the Browsers restrictions on accessing the local file system (& other restrictions) - that makes the workflow complicated to envision/setup.

Take the Tiddlywiki-on-Fission setup, for example. Fission.codes is basically creating a filesystem (in the browser's session storage memory AND on the p2p IPFS network at the same time). THIS is a context that Tiddlywiki can have native access to, as it doesn't matter where the file was loaded from, if the Browser has a Fission auth-key it will make changes to the local copy of the "webnative filesystem", and then push that to the p2p IPFS network once it has an internet connection.

I can totally see a check-in/check-out workflow for both public and private tiddlywikis on that platform, to allow "serial editing", & the user can always hit the download button (or go to the Fission Files app, and download the most recently saved html file) to have offline backup copies.

I think I may have something cool to show with the "realtime multiplayer" code for Bob2.0 I am designing here soon, so that may change a lot of these concerns.

Best,
Joshua Fontany

[AnthonyMuscio]

Joshua,

I am afraid I don't know about Tiddlywiki-on-Fission and little about IPFS however I have designed and in part tested but not finalised, a method by which changes can remain in local storage until back on line, but can only be committed once the current user has checked out the document.

I look forward to seeing your work, on realtime multiplayer. I will look up the conversations.

More details

Basically you build into the wiki the Ability to address (and avoid contention) not just between serial editors but between local storage and the checked out wiki. This allows multiple users to make multiple changes off line (in local storage) but manage checkout and commit process when online.

It is actually simple to craft the TiddlyWiki to avoid contention (over time), like allow a user with checkout, to comment on, but not overwrite, another users tiddlers (createdby). Giving the user their own namespace and tags and use master tiddlers to pull in (transclude) the content of all users.

All we need is serial editing to stop a set of tiddlers overwrite another set of tiddlers from another wiki editor.

Of course there needs to be trusted users because this can be all hacked and destroyed by any user with file access. We need something different for use by the "great unwashed" internet.

Tony

[AnthonyMuscio]

Bump,

I really want to restate Check in and out [is] critical to the use of tiddlywiki this is a serious barrier to publishing interactive wikis on the internet. I am confident we are already close to achieving this, I have a number of possible methods I have tested, but I need the support of a developer with knowledge of the save mechaisium or savers or other hosting issues like php.

Remember we have a broad set of circumstances and these includes a group of users on a LAN each using Timimi or TiddlyServer sharing single file wikis on node, in these cases all users are trusted users and have save rights. We need to control this at the application layer, although it can reach down to the file save mechanisms.

Regards
Tones